Jump to content

Высокая нагрузка на хостинг, что делать?

Featured Replies

Здравствуйте! Беда у меня, помогите!

Предисловие. Довольно продолжительное время я создавал сайт на базе IPB. А именно файловый каталог. Все остальные вещи, присущие форуму, я отключил или скрыл за ненадобностью. Каталог в данный момент содержит около 2000 файлов, которые находятся на сторонних файлообменниках.

В общем открыл я сайт 10 февраля. В первый день посещаемость была в ~500 уников. В течении этой недели постоянно в промежутке 200-300. Онлайн 10-30 человек практически постоянно. Сегодня получаю письмо от хостера (IHC, если что) вот такого содержания:

"Здравствуйте. Услуга база данных «base_name» в вашем заказе pXXXXXX заблокирована по причине: Скрипты Вашего сайта создавали критическую нагрузку на сервер."

Я направился в панель хостера, и обнаружил, что с 10 февраля нагрузка действительно превышена в 3-5 раз каждый день.

Попросил хостера разблокировать мне базу, чтобы устранить проблему.

Отправился в адмику IPB. В панели IPB в поле "Нагрузка на сервер" стояло число 4.22

Прошерстил интернет в поисках, наткнулся на одну теорию, а именно, что робот Google создает нагрузку, ибо сайт новый, и бот сейчас усиленно кушает странички. Действительно, с 10 числа Google практически 24/7 проводил время на сайте. А судя логам из IP.SEO с 12 числа наблюдался особый рост индексации. Решил я проверить данную теорию, и запретил через robots.txt всем поисковикам доступ. Итог: Google все равно в списке онлайн, и просматривает страницы, хотя в журнале посещений он не появлялся уже часа 4 (обычно почти каждые 5-10 минут отмечается). Собственно как узнать, действует ли запрет, или Google игнорирует все запреты?

Дальше – больше.

Направился я в настройки, и прошелся по всем пунктам, чтобы настроить те, которые помогли бы в оптимизации.

Потыкал некоторые пункты и отправился в журналы, а именно в Журнал задач, где обнаружил выполнение каждые 10 минут вот такой задачки "Мобильные уведомления НЕ МОГУТ БЫТЬ отправлены из-за ошибки с лицензионных ключом" Вот собственно дальше я зашел Планировщик задач и начал вырубать все подряд, что на мой взгляд показалось ненужным.

До кучи зашел в Инструменты управления SQL, и оптимизировал таблицы.

После всех этих манипуляций число нагрузки упало до 3.6

Я уже обрадовался, но видимо рано...

Доковырялся видимо до такого, что сейчас обнаружил, что не работает ни одна функция, связанная со всплывающими элементами: карточка профиля, уведомления, ЛС, кнопки листания файлов на главной, кнопка смены стиля, ББ-коды...

Теперь сижу и вообще не знаю что делать. Толком так и не выяснил, откуда нагрузка, и видимо еще и яву поломал каким-то образом.

Собственно, интересует вопрос: может ли при таком количестве уников, и с таким онлайном создаваться подобная нагрузка? Мне это лично кажется странным, ладно бы 1000+ уников было, но 200... Даже не знаю.

И как мне починить поломанную Java? Есть идеи, как могло ее зацепить?

Вопрос с нагрузкой нужно решить как можно скорее, ибо сегодня-завтра опять прикроют. Чувствую придется на VPS переползать, а это для меня дороговато...

Буду рад любым идеям, спасибо за помощь заранее!

Edited by Kinkl

Link to comment
https://ipbmafia.ru/topic/3092-vysokaya-nagruzka-na-hosting-chto-delat/
Share on other sites

Я знаю кто сможет из всего этого что-то понять, но не буду напрягать того человека :)

Собственно как узнать, действует ли запрет, или Google игнорирует все запреты?

Запрет действует.

 

Потыкал некоторые пункты и отправился в журналы, а именно в Журнал задач, где обнаружил выполнение каждые 10 минут вот такой задачки "Мобильные уведомления НЕ МОГУТ БЫТЬ отправлены из-за ошибки с лицензионных ключом"

Мобильные уведомления работают с серверами IPS, поэтому, само собой, в nulled версии они заблокированы.

 

Доковырялся видимо до такого, что сейчас обнаружил, что не работает ни одна функция, связанная со всплывающими элементами: карточка профиля, уведомления, ЛС, кнопки листания файлов на главной, кнопка смены стиля, ББ-коды...

Да, вы действительно сломали JS, что вы там делали в АЦ?

Приложите лог ошибок из консоли браузера.

 

Собственно, интересует вопрос: может ли при таком количестве уников, и с таким онлайном создаваться подобная нагрузка?

Ну, раз у вас такая нагрузка есть — значит может.

 

Вопрос с нагрузкой нужно решить как можно скорее, ибо сегодня-завтра опять прикроют. Чувствую придется на VPS переползать, а это для меня дороговато...

Нужно узнавать что конкретно создает эту нагрузку, это вообще странно, учитывая то, что файлы хранятся не на вашем сервере. Обратитесь к хостингу, попросите подробную статистику.

_Dark_, спасибо за ответ.

Уже начал писать пост, где я лазил в настройках, попутно копируя названия пунктов, как дошел до Подгружать javascript файлы из серверов Google. Собственно в этом проблема и была. Дурная голова рукам покоя не дает, наверное за компанию поставил Да :D Установил на Нет, все заработало.

Про нагрузку. Хостеру сейчас отпишу, чтобы статистику выслал. Боюсь как-бы не пришлось в конечном итоге переходить на VPS, все к этому и идет.

Глянул опять в панели хостера на числа, расклад такой:

С 17:00 нагрузка: на CPU=15, на MySQL=194

Суммарно на сегодняшний час уже CPU=114, MySQL=1167, что уже превышает порог в CPU=72 и MySQL=700.

Кстати, вопрос вдогонку сразу: такая система подсчета у всех хостингов используется? То есть суммируемая нагрузка по часам.

Edited by Kinkl

_Dark_, спасибо за ответ.

Уже начал писать пост, где я лазил в настройках, попутно копируя названия пунктов, как дошел до Подгружать javascript файлы из серверов Google. Собственно в этом проблема и была. Дурная голова рукам покоя не дает, наверное за компанию поставил Да :D Установил на Нет, все заработало.

Про нагрузку. Хостеру сейчас отпишу, чтобы статистику выслал. Боюсь как-бы не пришлось в конечном итоге переходить на VPS, все к этому и идет.

Глянул опять в панели хостера на числа, расклад такой:

С 17:00 нагрузка: на CPU=15, на MySQL=194

Суммарно на сегодняшний час уже CPU=114, MySQL=1167, что уже превышает порог в CPU=72 и MySQL=700.

Кстати, вопрос вдогонку сразу: такая система подсчета у всех хостингов используется? То есть суммируемая нагрузка по часам.

 

Давал ссылку уже... Повторюсь : На приведённом ниже хостинге сайтов тебе не выдаётся какое то определённое количесво ресурсов сервера, всё ограничивается заказанными тобой компонентами. __forum.zlofenix.org/t4786

Итак, пришел ответ на вопрос о нагрузке:

"Чаще всего в лог попадает скрипт /home/p26ххх/www/сайт.ru/index.php"

То есть получается главная дает такую нагрузку? Я не совсем понял если честно.

Забыл добавить, вдруг это важно: при обращении по www.сайт.ру у меня грузится именно компонент IP.Downloads, я прописал его в initdata.php. Это может влиять на что-нибудь?

Вот содержимое index.php

<?php
/**
 * <pre>
 * Invision Power Services
 * IP.Board v3.3.4
 * Main public executable wrapper.
 * Set-up and load module to run
 * Last Updated: $Date: 2012-06-12 10:14:49 -0400 (Tue, 12 Jun 2012) $
 * </pre>
 *
 * @author 		$Author: bfarber $
 * @copyright	(c) 2001 - 2009 Invision Power Services, Inc.
 * @license		__www.invisionpower.com/company/standards.php#license
 * @package		IP.Board
 * @link		__www.invisionpower.com
 * @version		$Rev: 10914 $
 *
 */	

define( 'IPB_THIS_SCRIPT', 'public' );
require_once( './initdata.php' );/*noLibHook*/

require_once( IPS_ROOT_PATH . 'sources/base/ipsRegistry.php' );/*noLibHook*/
require_once( IPS_ROOT_PATH . 'sources/base/ipsController.php' );/*noLibHook*/

ipsController::run();

exit();
А на DDOS подозрений нету ?

Edited by _Dark_
Необязательно цитировать все сообщения, включая код

Я уже и не знаю что думать если честно... Как можно проверить? Вообще такая нагрузка практически с открытия сайта была, онлайн постоянный 20 сегодня. В списке смотрел, все что-то просматривают, при ддос такое вряд-ли бы было наверное, там обычно главная страница указана.

Итак, пришел ответ на вопрос о нагрузке: "Чаще всего в лог попадает скрипт /home/p26ххх/www/сайт.ru/index.php" То есть получается главная дает такую нагрузку? Я не совсем понял если честно.

 

Это не то что нужно. В IP.Board одна точка входа, поэтому все запросы идут через index.php, index.php — это не главная страница.

Попросите у них параметры с которыми открывается index.php, т.е. GET запросы к ней в момент пиковой нагрузки.

у меня посещаемость 1500-2000 причем кроме файлового архива работает еще и форум, content, блоги, туториалс, магазин, и видео хостинг системс.

 

post-728-0-52712100-1361032915_thumb.png

Edited by andreuka

_Dark_, отписал им, жду ответа. В режиме отладки кстати еще посмотрел, вот что там: Время исполнения: 0,5860 Загрузка: -- Запросов: 19 запросов.

andreuka, хостинг тоже IHC? Какой тариф/VPS? Цифры вообще в сравнение с моими не идут... Вот я уже вообще не представляю что может быть такое, и в какую сторону копать. Ненормальная нагрузка у меня значит совсем.


В режиме отладки кстати еще посмотрел, вот что там: Время исполнения: 0,5860 Загрузка: -- Запросов: 19 запросов.

Что-то мне подсказывает, что эту нагрузку создает БД.  

Я уже устал поднимать этот вопрос. Поэтому и молчу. Моим хостером мне было сказано однозначно эту нагрузку создает БД. Иногда по неизвестной (мне) причине, иногда зависают скрипты при обращении к БД. Мне говорят типа смотри настройки. Делаю по рекомендациям и хрен там. Плюнул. Иногда сервак перезагружаю и все. Устал искать причины.

Итак, пришел ответ.

Эти данные Вы можете найти в файле access_log , в каталоге logs.

Захожу я в папку и вижу... файл размером 240 МБ! Это явно не нормально? Внутри 815.194 строки! Что мне искать хотя бы примерно?

"Эти" данные ты там не найдешь. В файле отображается только кто и какой запрос дал. Времени исполнения запроса и его длительности в файле нет. Ловить нечего.

Kinkl,удалите этот файл, там уже не разберетесь. После этого напишите хостерам, попросите их при любой подозрительно высокой нагрузке сообщить вам, с точным указанием времени.

Затем открываете этот файл ищите указанное время и пишите нам сюда запрос, который там в файле указан.


И да, в размере файла нет ничего странного, все в норме.

У меня конечно дебильный вопрос, но как удалить этот самый лог? Из ФТП никак не получается: 550 access.log: Permission denied

Ты видимо никак. Написано что у тебя не хватает прав :(

access_log = лог посищений твоего сайта.

Edited by Death1

Kinkl, попробуйте из панель управления, если там есть менеджер файлов. 

_Dark_, не удаляется сволочь... Пробовал по FTP Admin, ни один файл из папки не удаляется.

По SSH через Putty пробовал, аналогично. Выдает:

[p26xxx@h13 logs]$ rm site.ru_access.log
rm: remove write-protected regular file `site.ru_access.log'? y
rm: cannot remove `site.ru_access.log': Permission denied

_Dark_, не удаляется сволочь... Пробовал по FTP Admin, ни один файл из папки не удаляется.

По SSH через Putty пробовал, аналогично. Выдает:

[p26xxx@h13 logs]$ rm site.ru_access.log
rm: remove write-protected regular file `site.ru_access.log'? y
rm: cannot remove `site.ru_access.log': Permission denied

Смени chmod 

_Dark_, не удаляется сволочь... Пробовал по FTP Admin, ни один файл из папки не удаляется.

По SSH через Putty пробовал, аналогично. Выдает:

[p26xxx@h13 logs]$ rm site.ru_access.log
rm: remove write-protected regular file `site.ru_access.log'? y
rm: cannot remove `site.ru_access.log': Permission denied

а попробуй через SSH так cat /dev/null > site.ru_access.log либо chmod 777 site.ru_access.log && rm site.ru_access.log. но почемуто мне кажется это общий лог всех сайтов... Вообще посмотри в начале какого пользователя он, если не твой - забей на него или обратись к сис админу. Пингвин очень хорош в разграничении прав на всё что есть.


Смени chmod

Пробовал конечно, аналогично, не дает менять

Death1, лог мой, тут просто помимо этого лога лежат еще логи второго сайта. Тут общий вес оказывается на 935 МБ уже

Попросите хостера очистить его, потому что с таким объемом данных работать будет проблематично.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.


Guest
Ответить в этой теме...

Последние посетители 0

  • No registered users viewing this page.