Продолжаем хаить форум

[Serg]

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

У PHP есть глобальное ограничение на время работы скрипта, поставь там секунд 10 или даже 5 - подвисать перестанет и в логах можно будет видеть в какие моменты возникают тормоза.
И показал-бы top - может дело не в apache...

[SVP]

А нельзя-ли попросту переделать так, чтобы графика выдавалась без скриптов ?
Или какой-то секьюрити ризон есть ? Как по мне, так это немного диковато, когда для получения картинок php дёргается.

[xvovanx]

По тихоньку чищу скрипт

Ааа, теперь понятно почему за полдня 6 раз выкидывало с форума. Сидишь, читаешь - глядь и ты уже только читатель, а не "писатель"

[Nick]

А нельзя-ли попросту переделать так, чтобы графика выдавалась без скриптов ?

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

У PHP есть глобальное ограничение на время работы скрипта, поставь там секунд 10 или даже 5 - подвисать перестанет

Тут тоже есть прикол - файлы почему-то отдает в chunks по 8к. Если будет медленный коннекшн скачать большой файл будет проблематично.

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

			while (!feof($fp))
			{
				echo fread($fp, 8192);
			}
			fclose($fp);

И показал-бы top - может дело не в apache...

Это извиняюсь, забыл - не увуидел там ничего нового и не выложил.
Единственный процесс с большой цифрой - это mysql - но он висит постоянно поэтому у нем прилично затраченного процессороного времени, в момент нагрузки он жрет не много.

Ааа, теперь понятно почему за полдня 6 раз выкидывало с форума

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

[SVP]

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

Да фиг бы с ними с конфигами... картинки-то нафига прятать ? А аватары ? Графика наверняка занимает 99%+ файлов.
И как-то сомневаюсь я, что она в каких-то "закрытых" форумах есть и ээээ... вообще там нужна .
Но тут да, как-то колечить движок придется...
Смайлы хоть хорошо не через скрипты выдаются...

PS. Всё-таки, наверное нгикс поставить и расслабиться. Из апача в нгикс будет отдаваться мгновенно, и процессы будут нормально освобождаться.

[MX_Master]

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

В порядке бреда - с одного IP на форум заходят разные юзеры. Из-за динамической выдачи IP'шников провайдером.

[Nick]

Я так понимаю, что session id хранится в кукизах и оттуда берется, привязки по ip нет.
Когда я хочу зайти за админа, я просто открываю окно в режиме инкогнито и логинюсь там за админа, не выходя из основоного аккаунта. И оба работают нормально.

[Nick]

Хммм... пока лучше не стало...
вот график по загруженности памяти и количеству апачей с шагом в 2 секунды.
С 200 до 516 процессов прошло около 48 секунд...

[xvovanx]

А вы точно всякие режимы инкогнито в браузере не включаете?

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

[NikolayUa24]

Со смарта сегодня не получилось зайти весь день.

[Nick]

Странно, что запрос может долго висеть даже для маленьких файлов.
Удалось смоделировать похожую ситуацию, при помощи wget с ограничением скорости скачивания - подвисает поток в состоянии W - sending reply.
Не пробуйте повторять! Пожалуйста!
wget --limit-rate 6k http://cncxxx-club.ru/forum/download/fi ... &mode=view

[Nick]

Хммм накопал вот такую настройку:

Безопасные cookie [ https ]:
Если ваш сервер работает через SSL, то включите этот параметр. В противном случае оставьте выключенным. Включение этого параметра, если сервер работает не через SSL, приведёт к ошибкам при переходах по страницам конференции и при переадресации.

Чтобы это значило , может это то из-за чего людей разлогинивает из форума? Хотя вроде попробовал зайти и через https и без и ничего такого не произошло...

[Serg]

Единственный процесс с большой цифрой - это mysql - но он висит постоянно поэтому у нем прилично затраченного процессороного времени, в момент нагрузки он жрет не много.

А что происходило во время снятия второго и третьего скриншота?
По первым прикидкам я бы порекомендовал добавить серверу RAM - ему похоже хочется больше памяти под кэш и буферы. Ну и немного скорректировать настройки mysql в этом направлении.
Есть возможность увидеть график загрузки сетевого интерфейса в виде графика за последние сутки? У Хетцнера вроде есть такая возможность...
Вообще для наблюдения за работой сервера имеет смысл запустить sar: https://www.ibm.com/developerworks/ru/l ... index.html
Ещё полезная утилита для изучения текущего состояния - nmon.

PS. Всё-таки, наверное нгикс поставить и расслабиться. Из апача в нгикс будет отдаваться мгновенно, и процессы будут нормально освобождаться.

По top видно, что никакой ngnix не нужен или только хуже сделает - большой нагрузки на диск нет.
Самым лучшим вариантом по прежнему считаю установку лимитов на количество коннектов для поисковиков или просто для всех. Причём полагаю при превышении лимита не выдавать никаких отлупов и ошибок, а просто игнорить запрос - это должно помочь равномернее "размазать во времени" запросы от поисковиков, они всё равно с форума не уйдут.

Чтобы это значило , может это то из-за чего людей разлогинивает из форума? Хотя вроде попробовал зайти и через https и без и ничего такого не произошло...

Это для случая, когда обращение к сайту по http будет сразу переадресовываться на https.
Я думаю "разлогин" происходит потому, что из-за задержек и "обрывов" некорректно обновляются куки...

[Nick]

А что происходило во время снятия второго и третьего скриншота?

Ты имеешь в виду большой процент CPU на mysql? Скорее всего так повезло, скорее всего несколько раз быстро обновил top - там сам топ тоже в топе с 28%.
Н а третьем ничего особенного не вижу.
Все эти скриншоты на сколько я помню сняты во время проблемы в течение 30 секуд, просто сортировка по разным столбцам.

По первым прикидкам я бы порекомендовал добавить серверу RAM

Там 16Гб для обычной работы хватает. 90+% занято апачем. Я возможно не правильно умножил в статистике по памяти занимемой апачем, но его там много. Точно 0.1*500%, т.е. как минимум 50% есть, но скорее всего больше.

Вообще для наблюдения за работой сервера имеет смысл запустить sar: https://www.ibm.com/developerworks/ru/l ... index.html
Ещё полезная утилита для изучения текущего состояния - nmon.

+1 изучу вопрос.


Что думаешь на счет этого:

Странно, что запрос может долго висеть даже для маленьких файлов.
Удалось смоделировать похожую ситуацию, при помощи wget с ограничением скорости скачивания - подвисает поток в состоянии W - sending reply.
Не пробуйте повторять! Пожалуйста!
wget --limit-rate 6k http://cncxxx-club.ru/forum/download/fi ... &mode=view

Меня удивляет, что проблема только с яндексом.
Вроде как ничего особенного в скрипте нет, все, что можно я убрал, остальное не должно зависеть от того кто качает файл.

И да, set_time_limit(20) не влияет - всеравно висят процессы с временем выполнения больше 2 минут. В php стоит глобальный лимит 30 секунд, он тоже ничего не дает.
При этом можно спокойно скачивать файл достаточно долго.
Хотя php может уже к жтому моменту заканчивает работу, я так понял, что дробление файла на куски нужно для того, чтобы не занимать память. Вполне возможно, что он быстро отдает файл в апач, а он уже долго отправляет его клиенту.

[Serg]

Ты имеешь в виду большой процент CPU на mysql? Скорее всего так повезло, скорее всего несколько раз быстро обновил top - там сам топ тоже в топе с 28%.

Там апачей не видно, а LoadAverage выше, чем на первом, где куча апачей...

Там 16Гб для обычной работы хватает. 90+% занято апачем. Я возможно не правильно умножил в статистике по памяти занимемой апачем, но его там много. Точно 0.1*500%, т.е. как минимум 50% есть, но скорее всего больше.

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

Что думаешь на счет этого:

Тут всё логично - поток будет висеть пока всё не отдаст, ибо по сети отдаётся не сразу весь файл, а последовательными "кусочками" примерно по килобайту. Ненужные "куски" этого экземпляра потока/апача ресурсы не потребляют и при надобности их могут даже выкинуть из памяти.

И да, set_time_limit(20) не влияет - всеравно висят процессы с временем выполнения больше 2 минут. В php стоит глобальный лимит 30 секунд, он тоже ничего не дает.

Да, после картинок уже понятно, что дело не в ресурсах, занимаемых апачем или php... Всё больше и больше хочется посмотреть график загрузки интерфейса...

[Nick]

Там апачей не видно, а LoadAverage выше, чем на первом, где куча апачей...

Там сортировка по процессорному времени. Апачи живут не долго у них стоит ограничение на 1000 запросов, потом процесс перезапускается. Кстати апач работает в режиме mpm_itk - так что может он вообще на каждый запрос заново создает потомка. Поэтому апачей не видно, но видно кто больше всего грузил систему - и это mysql суммарно около 700 секунд процессорного времени за несколько дней.

[Nick]

Да, после картинок уже понятно, что дело не в ресурсах, занимаемых апачем или php...

Апач всетаки память потребляет.

Всё больше и больше хочется посмотреть график загрузки интерфейса...

Какой график?

[Nick]

и это mysql суммарно около 700 секунд процессорного времени за несколько дней.

хммм это не секунд, а минут...

[Serg]

Кстати апач работает в режиме mpm_itk - так что может он вообще на каждый запрос заново создает потомка. Поэтому апачей не видно, но видно кто больше всего грузил систему - и это mysql суммарно около 700 секунд процессорного времени за несколько дней.

это всё с помощью ps можно посмотреть:

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

$ ps ax | grep mysql
ps ax | grep mysql
 1247 ?        Ss     0:00 /bin/sh /usr/bin/mysqld_safe --basedir=/usr
 1614 ?        Sl   7200:09 /usr/libexec/mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr/lib64/mysql/plugin --log-error=/var/log/mariadb/mariadb.log --pid-file=/var/run/mariadb/mariadb.pid --socket=/var/lib/mysql/mysql.sock

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

$ ps axH | grep mysql
 1247 ?        Ss     0:00 /bin/sh /usr/bin/mysqld_safe --basedir=/usr
 1614 ?        Sl    12:09 /usr/libexec/mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr/lib64/mysql/plugin --log-error=/var/log/mariadb/mariadb.log --pid-file=/var/run/mariadb/mariadb.pid --socket=/var/lib/mysql/mysql.sock
 1614 ?        Sl     4:19 /usr/libexec/mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr/lib64/mysql/plugin --log-error=/var/log/mariadb/mariadb.log --pid-file=/var/run/mariadb/mariadb.pid --socket=/var/lib/mysql/mysql.sock
 1614 ?        Sl     4:42 /usr/libexec/mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr/lib64/mysql/plugin --log-error=/var/log/mariadb/mariadb.log --pid-file=/var/run/mariadb/mariadb.pid --socket=/var/lib/mysql/mysql.sock
 1614 ?        Sl     4:12 /usr/libexec/mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr/lib64/mysql/plugin --log-error=/var/log/mariadb/mariadb.log --pid-file=/var/run/mariadb/mariadb.pid --socket=/var/lib/mysql/mysql.sock
 1614 ?        Sl     4:13 /usr/libexec/mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr/lib64/mysql/plugin --log-error=/var/log/mariadb/mariadb.log --pid-file=/var/run/mariadb/mariadb.pid --socket=/var/lib/mysql/mysql.sock
 1614 ?        Sl     4:10 /usr/libexec/mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr/lib64/mysql/plugin --log-error=/var/log/mariadb/mariadb.log --pid-file=/var/run/mariadb/mariadb.pid --socket=/var/lib/mysql/mysql.sock
 1614 ?        Sl     4:08 /usr/libexec/mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr/lib64/mysql/plugin --log-error=/var/log/mariadb/mariadb.log --pid-file=/var/run/mariadb/mariadb.pid --socket=/var/lib/mysql/mysql.sock
 1614 ?        Sl     6:08 /usr/libexec/mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr/lib64/mysql/plugin --log-error=/var/log/mariadb/mariadb.log --pid-file=/var/run/mariadb/mariadb.pid --socket=/var/lib/mysql/mysql.sock
 1614 ?        Sl     4:02 /usr/libexec/mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr/lib64/mysql/plugin --log-error=/var/log/mariadb/mariadb.log --pid-file=/var/run/mariadb/mariadb.pid --socket=/var/lib/mysql/mysql.sock
 1614 ?        Sl     4:10 /usr/libexec/mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr/lib64/mysql/plugin --log-error=/var/log/mariadb/mariadb.log --pid-file=/var/run/mariadb/mariadb.pid --socket=/var/lib/mysql/mysql.sock
 1614 ?        Sl     5:49 /usr/libexec/mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr/lib64/mysql/plugin --log-error=/var/log/mariadb/mariadb.log --pid-file=/var/run/mariadb/mariadb.pid --socket=/var/lib/mysql/mysql.sock
 1614 ?        Sl    99:14 /usr/libexec/mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr/lib64/mysql/plugin --log-error=/var/log/mariadb/mariadb.log --pid-file=/var/run/mariadb/mariadb.pid --socket=/var/lib/mysql/mysql.sock
 1614 ?        Sl   159:52 /usr/libexec/mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr/lib64/mysql/plugin --log-error=/var/log/mariadb/mariadb.log --pid-file=/var/run/mariadb/mariadb.pid --socket=/var/lib/mysql/mysql.sock
 1614 ?        Sl     0:27 /usr/libexec/mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr/lib64/mysql/plugin --log-error=/var/log/mariadb/mariadb.log --pid-file=/var/run/mariadb/mariadb.pid --socket=/var/lib/mysql/mysql.sock
 1614 ?        Sl     0:24 /usr/libexec/mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr/lib64/mysql/plugin --log-error=/var/log/mariadb/mariadb.log --pid-file=/var/run/mariadb/mariadb.pid --socket=/var/lib/mysql/mysql.sock
 1614 ?        Sl    41:29 /usr/libexec/mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr/lib64/mysql/plugin --log-error=/var/log/mariadb/mariadb.log --pid-file=/var/run/mariadb/mariadb.pid --socket=/var/lib/mysql/mysql.sock
 1614 ?        Sl    15:12 /usr/libexec/mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr/lib64/mysql/plugin --log-error=/var/log/mariadb/mariadb.log --pid-file=/var/run/mariadb/mariadb.pid --socket=/var/lib/mysql/mysql.sock
 1614 ?        Sl     0:04 /usr/libexec/mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr/lib64/mysql/plugin --log-error=/var/log/mariadb/mariadb.log --pid-file=/var/run/mariadb/mariadb.pid --socket=/var/lib/mysql/mysql.sock
 1614 ?        Sl     0:00 /usr/libexec/mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr/lib64/mysql/plugin --log-error=/var/log/mariadb/mariadb.log --pid-file=/var/run/mariadb/mariadb.pid --socket=/var/lib/mysql/mysql.sock
 1614 ?        Sl     0:01 /usr/libexec/mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr/lib64/mysql/plugin --log-error=/var/log/mariadb/mariadb.log --pid-file=/var/run/mariadb/mariadb.pid --socket=/var/lib/mysql/mysql.sock
 1614 ?        Sl     0:00 /usr/libexec/mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr/lib64/mysql/plugin --log-error=/var/log/mariadb/mariadb.log --pid-file=/var/run/mariadb/mariadb.pid --socket=/var/lib/mysql/mysql.sock
 1614 ?        Sl     0:01 /usr/libexec/mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr/lib64/mysql/plugin --log-error=/var/log/mariadb/mariadb.log --pid-file=/var/run/mariadb/mariadb.pid --socket=/var/lib/mysql/mysql.sock
 1614 ?        Sl     0:00 /usr/libexec/mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr/lib64/mysql/plugin --log-error=/var/log/mariadb/mariadb.log --pid-file=/var/run/mariadb/mariadb.pid --socket=/var/lib/mysql/mysql.sock
 1614 ?        Sl     0:00 /usr/libexec/mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr/lib64/mysql/plugin --log-error=/var/log/mariadb/mariadb.log --pid-file=/var/run/mariadb/mariadb.pid --socket=/var/lib/mysql/mysql.sock
 1614 ?        Sl     0:00 /usr/libexec/mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr/lib64/mysql/plugin --log-error=/var/log/mariadb/mariadb.log --pid-file=/var/run/mariadb/mariadb.pid --socket=/var/lib/mysql/mysql.sock
 1614 ?        Sl     0:00 /usr/libexec/mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr/lib64/mysql/plugin --log-error=/var/log/mariadb/mariadb.log --pid-file=/var/run/mariadb/mariadb.pid --socket=/var/lib/mysql/mysql.sock
 1614 ?        Sl     0:00 /usr/libexec/mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr/lib64/mysql/plugin --log-error=/var/log/mariadb/mariadb.log --pid-file=/var/run/mariadb/mariadb.pid --socket=/var/lib/mysql/mysql.sock
 1614 ?        Sl     0:00 /usr/libexec/mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr/lib64/mysql/plugin --log-error=/var/log/mariadb/mariadb.log --pid-file=/var/run/mariadb/mariadb.pid --socket=/var/lib/mysql/mysql.sock
 1614 ?        Sl     0:01 /usr/libexec/mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr/lib64/mysql/plugin --log-error=/var/log/mariadb/mariadb.log --pid-file=/var/run/mariadb/mariadb.pid --socket=/var/lib/mysql/mysql.sock

Апач всетаки память потребляет.

Потребление памяти не будет так сильно всё тормозить - своп по сути не задействован. Я нехватка памяти в первую очередь будет компенсироваться за счёт кэша и буферов.

Какой график?

График загрузки сетевого интерфейса. Типа такого:

Поищи в ЛК или запроси у сапорта.
Ну или подскажу как на самом сервере такую статистику собирать...

[Nick]

поставил писаться статистику...
через часик другой сделаем график.