[John Smith]

rxu писал(а):А что логи говорят? Какие конкретно PHP скрипты и/или SQL запросы грузят процессор?

Подобных логов в цпанели не вижу. Вижу только вот такое (см. картинку). Скачек нагрузки регулярно приходится на 22 часа.
Кстати, падение в 2 раза между 23 и 1 часом ночи - это я как раз ботам закрыл доступ, и почистил таблицу сессий.

rxu писал(а):John Smith
Ботам сиды не выдаются.

Т.е., если я правильно понял, к группе ботов применяются какие-то особые политики? Гостям сиды даются, а ботам нет? А то я в админке ничего подобного не нашел.

rxu писал(а):John Smith
Возможно, потому, что дело было не в этом. Из-за трёхсот записей в таблице в десять раз возрастает нагрузка на ЦП? Вряд ли.

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

rxu писал(а):John Smith
И каковы параметры железа вашего хостинга?

Хостинг-сервера построены на базе оборудования Dual AMD 64 Opteron 2 Ггц, не менее 2 Гб ОЗУ и Raid массивами с ежедневным резервным копированием данных.

Это все, что известно.

Update: Только что специально проверил - гость получает сид, бот не получает сид. Как оно работает - не ясно.

[John Smith]

Развитие ситуации.
Посмотрев, что нагрузка падает, открыл доступ поисковикам к одному из разделов форума, около 20:00. Как видно из графика ниже, нагрузка не ползла вверх. Потом, уже около 23:00, колупаючись в БД обнаружил, что таблица phpbb_sessions при количестве записей 6 шт. имела размер 1,2Мб. Непорядок. Посмотрев внимательно обнаружил, что она фрагментирована, и фрагментированный объем около 900 кб. Ну, ткнул "оптимизировать таблицу" - она оптимизировалась. Если я все правильно понял, это аналог команды "pack" для старых БД. А фрагментированный объем - записи, помеченные как удаленные, но на самом деле оставшиеся в таблице.
Через час после этой процедуры обратил внимание, что нагрузка еще сильнее упала (см. столбец 1 часа).
А вот сейчас обнаружил, что потом опять подпрыгнула. Куда копать, ума не приложу.

P.S. Забыл сказать - нагрузка на SQL и память скачет пропорционально нагрузке на проц. Только там детальных графиков нет - только суточный показатель.
И еще - самые большие таблицы в БД - phpbb_posts (7500 записей; 5,2 Мб), phpbb_search_wordlist (37500 записей; 3,3Мб), phpbb_search_wordmatch (150000 записей, 6,7Мб) - может, тут какая-то засада?

[VVVas]

John Smith
Засады никакой нет. Вопрос в том не разрешили ли вы случайно ботам чего лишнего вроде использования поиска и прочее.

[John Smith]

VVVas писал(а):John Smith
Вопрос в том не разрешили ли вы случайно ботам чего лишнего вроде использования поиска и прочее.

Я разрешил им только "видеть форум" и "читать форум", и то не на всю конференцию. По-умолчанию все было закрыто.

Update
Анализировал RAW log. Обнаружил несколько пиков по количеству GET-запросов. Например, один из них:
Время запросов/сек
13:45:23 42
13:45:47 37
13:45:48 57
13:45:49 85
13:45:50 60
13:45:51 38
13:45:52 37
13:45:53 31
13:45:55 35
13:45:56 32
Таких пиков всего 3 за 14 часов. Среднее значение: 6,7 запросов/сек. Если общее время (14 часов) поделить на общее число запросов, получится менее 1 GET-запроса в секунду.
Поисковики более 3 запросов/сек. не делали.
Для наглядности сделал график количества запросов/сек. (см. внизу).

Други, помогите - как бороть. Я новичок в вопросе. Может, какие средства диагностики есть? С учетом того, что хостинг виртуальный.

Update 2.
Так, похоже большое число одновременных запросов получают в ответ 304. Тогда можно понять, если тот-же IE может делать одновременно 4 соединения, а т.к. собственно данные передавать не надо, то происходит пинг-понг, типа GET - 304, что происходит быстрее. Хотя, 85 запросов от одного юзера все-равно подозрительно, но у него могло быть несколько окон, и т.д.
И вот еще что обнаружил - запросы от яндекса, типа:

Код: Выделить всё

GET /forum/viewtopic.php?p=5000&sid=0db175ec8770412192bdbd6c821762cf HTTP/1.1

Интересно, откуда сид взялся.

Добавлено спустя 8 часов 46 минут 32 секунды:

Кто про что, а больной про здоровье.
Пишу отдельным сообщением, дабы соблюсти некую хронологию. Прошу не бить.
В общем, картина маслом - опять загрузка прыгнула. И опять в 22.
Вот картинка.

[rxu]

А может, это тупо атаки, распределенные по времени?

[John Smith]

rxu писал(а):А может, это тупо атаки, распределенные по времени?

Может. Была такая мысль. Только вот такие пачки запросов приходят от зареганых и лояльных юзеров. Была мысль, может это вири играют на машинах юзеров, но что-то я в этом сомневаюсь.
И, опять-же, это никак не объясняет ежесуточные скачки в 22:00.
И почему бот получает сид, тоже не ясно.

Вот я как делаю - пишу себе в юзер агент строку типа "Yandex/1.01.001", и захожу на форум. Форум меня опознает как бота, пускает, куда можно, куда нельзя - не пускает. Лажу по форуму, сидов не вижу. А тут вот в логе, оказывается, есть такие запросы....

Стоп! А может это потому, что раньше яндекс гостем ходил? У него в кэше остались УРЛы с сидом, и он их тупо проверяет?

Но, опять-же, почему 22:00...

Добавлено спустя 18 минут 52 секунды:

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

По данным debug и explain.
Захожу на титульную страницу:
Time : 0.096s | 8 Queries | GZIP : Off | Memory Usage: 4.3 Mб
Page generated in 0.1044 seconds with 7 queries + 3 queries returning data from cache
Time spent on mysql4 queries: 0.00656s | Time spent on PHP: 0.09783s

Захожу в один из форумов:
Time : 0.743s | 8 Queries | GZIP : Off | Memory Usage: 4.5 Mб
Page generated in 0.1307 seconds with 8 queries + 4 queries returning data from cache
Time spent on mysql4 queries: 0.00933s | Time spent on PHP: 0.12137s

Захожу в топик:
Time : 0.503s | 12 Queries | GZIP : Off | Memory Usage: 6 Mб
Page generated in 1.4764 seconds with 11 queries + 6 queries returning data from cache
Time spent on mysql4 queries: 0.47921s | Time spent on PHP: 0.99717s

[amka]

Сколько памяти уходить на обработку одного скрипта в phpBB3?

Купил хостинг, но у него ограничение в 15 Мб на обработку 1-го php скрипта.
Проблема в том, что в темах сконверированных из phpdd2 в phpbb3 не могу оставлять новые сообщения. Выходит чистый лист. В логах написано:

[Sat Apr 26 00:55:27 2008] [error] [client 88.205.156.85] PHP Fatal error: Allowed memory size of 15728640 bytes exhausted (tried to allocate 1966080 bytes) in /usr/home/17642/gorodplast.net/html/includes/utf/data/utf_compatibility_decomp.php on line 2, referer: http://www.gorodplast.net/posting.php?m ... f=13&t=285

Я так понимаю, что не хватает памяти. Но, если я создаю новую тему и новое сообщение в новой теме, то все обрабатывается нормально.
Вопрос: Проблема в форуме или придется переходить на другой тарифный план, где выделяется 20 Мб на обработку 1-го php скрипта????

[rxu]

Проблемы в форуме нет - это нормальная работа phpBB3. В связи с тем, что конткент в UTF-8 занимает в несколько раз больше места в памяти, чем, например, в cp1251, для работы скриптов phpBB3 трребуется больше ресурсов.
Поэтому при возникновении подобной ошибки количество памяти под скрипт нужно увеличить.

[amka]

Спасибо!

Добавлено спустя 47 минут 33 секунды:

Вот только не понятно на сколько увеличить? 20МБ будет достаточно?

[Rayden]

Allowed memory size of 15728640 bytes exhausted (tried to allocate 1966080 bytes)

Сложи две цифры - узнаешь.
А вообще 32М стандарт на сегодняшний день.

[amka]

спасибо!
Значит 3-ка пока не для меня((

[toxi]

Я использую phpbb3 на сервере http://000webhost.com.
Не тормозит, работает отлично, удобная система администрирования.
Кто желает, может протестировать форум:
http://serviceplus.site88.net

[Rayden]

Это что за реклама? Какое отношение это имеет к теме?

[Mr. Anderson]

значит phpbb3 лутше чем phpbb2
__________________________________
[url=http://ссылка удвлена администратором]малолетки[/url]

[Erlang]

Сейчас прислали:

Вас приветствует компания .masterhost!

Уведомляем Вас, что работой базы данных MySQL создается повышенная нагрузка на
сервер баз данных. Примеры запросов находятся в прикрепленном файле.

Оптимизируйте, пожалуйста, Ваши скрипты, SQL-запросы и дайте нам знать о результатах.

Например, Вы можете использовать метод EXPLAIN для выяснения "тяжелых" запросов и создание
индексов (CREATE INDEX), тем самым снизив нагрузку на базу данных.

Обращаем Ваше внимание, что при сохранении нагрузки, мы будем вынуждены заблокировать
Вам услугу MySQL.

Из МОДов только Быстрый ответ и Последние темы

Вот прислали:

Код: Выделить всё

SELECT t.*,p.*,f.*,u.*
    FROM phpbb_topics AS t, phpbb_posts AS p, phpbb_forums AS f, phpbb_users AS u
    WHERE t.forum_id = f.forum_id
         AND t.forum_id NOT IN(20,26,32,49)

        AND p.post_id = t.topic_first_post_id
        AND t.topic_moved_id = 0
        AND t.topic_last_poster_id = u.user_id
    ORDER BY t.topic_last_post_id DESC LIMIT 20;


SELECT t.*,p.*,f.*,u.*
    FROM phpbb_topics AS t, phpbb_posts AS p, phpbb_forums AS f, phpbb_users AS u
    WHERE t.forum_id = f.forum_id
         AND t.forum_id NOT IN(20,26,32,49)

        AND p.post_id = t.topic_first_post_id
        AND t.topic_moved_id = 0
        AND t.topic_last_poster_id = u.user_id
    ORDER BY t.topic_last_post_id DESC LIMIT 20;


SELECT t.*,p.*,f.*,u.*
    FROM phpbb_topics AS t, phpbb_posts AS p, phpbb_forums AS f, phpbb_users AS u
    WHERE t.forum_id = f.forum_id
         AND t.forum_id NOT IN(20,26,32,49)

        AND p.post_id = t.topic_first_post_id
        AND t.topic_moved_id = 0
        AND t.topic_last_poster_id = u.user_id
    ORDER BY t.topic_last_post_id DESC LIMIT 20;


SELECT t.*,p.*,f.*,u.*
    FROM phpbb_topics AS t, phpbb_posts AS p, phpbb_forums AS f, phpbb_users AS u
    WHERE t.forum_id = f.forum_id
         AND t.forum_id NOT IN(20,26,32,49)

        AND p.post_id = t.topic_first_post_id
        AND t.topic_moved_id = 0
        AND t.topic_last_poster_id = u.user_id
    ORDER BY t.topic_last_post_id DESC LIMIT 20;


SELECT t.*,p.*,f.*,u.*
    FROM phpbb_topics AS t, phpbb_posts AS p, phpbb_forums AS f, phpbb_users AS u
    WHERE t.forum_id = f.forum_id
         AND t.forum_id NOT IN(20,26,32,49)

        AND p.post_id = t.topic_first_post_id
        AND t.topic_moved_id = 0
        AND t.topic_last_poster_id = u.user_id
    ORDER BY t.topic_last_post_id DESC LIMIT 20;


SELECT t.*,p.*,f.*,u.*
    FROM phpbb_topics AS t, phpbb_posts AS p, phpbb_forums AS f, phpbb_users AS u
    WHERE t.forum_id = f.forum_id
         AND t.forum_id NOT IN(20,26,32,49)

        AND p.post_id = t.topic_first_post_id
        AND t.topic_moved_id = 0
        AND t.topic_last_poster_id = u.user_id
    ORDER BY t.topic_last_post_id DESC LIMIT 20;


SELECT t.*,p.*,f.*,u.*
    FROM phpbb_topics AS t, phpbb_posts AS p, phpbb_forums AS f, phpbb_users AS u
    WHERE t.forum_id = f.forum_id
         AND t.forum_id NOT IN(20,26,32,49)

        AND p.post_id = t.topic_first_post_id
        AND t.topic_moved_id = 0
        AND t.topic_last_poster_id = u.user_id
    ORDER BY t.topic_last_post_id DESC LIMIT 20;


SELECT t.*,p.*,f.*,u.*
    FROM phpbb_topics AS t, phpbb_posts AS p, phpbb_forums AS f, phpbb_users AS u
    WHERE t.forum_id = f.forum_id
         AND t.forum_id NOT IN(20)

        AND p.post_id = t.topic_first_post_id
        AND t.topic_moved_id = 0
        AND t.topic_last_poster_id = u.user_id
    ORDER BY t.topic_last_post_id DESC LIMIT 20;


SELECT t.*,p.*,f.*,u.*
    FROM phpbb_topics AS t, phpbb_posts AS p, phpbb_forums AS f, phpbb_users AS u
    WHERE t.forum_id = f.forum_id
         AND t.forum_id NOT IN(20,26,49)

        AND p.post_id = t.topic_first_post_id
        AND t.topic_moved_id = 0
        AND t.topic_last_poster_id = u.user_id
    ORDER BY t.topic_last_post_id DESC LIMIT 20;


SELECT t.*,p.*,f.*,u.*
    FROM phpbb_topics AS t, phpbb_posts AS p, phpbb_forums AS f, phpbb_users AS u
    WHERE t.forum_id = f.forum_id
         AND t.forum_id NOT IN(20)

        AND p.post_id = t.topic_first_post_id
        AND t.topic_moved_id = 0
        AND t.topic_last_poster_id = u.user_id
    ORDER BY t.topic_last_post_id DESC LIMIT 20;