An original idea. That can't be too hard. The library must be full of them. (c)Stephen Fry
/>>> 05.03.2015, 12:00, "Support Team":
/>>> Здравствуйте!
/>>>
/>>> Действительно, нагрузка на сервер не снизилась. В таком случае требуется проверка скриптов Вашего сайта с помощью его разработчика.
/>>>
/>>> В частности, вчера произведено порядка 1200 запросов к скрипту sсript_naduv.php:
/>>>
/>>> [username@shared ~/logs]$ cat custom_log.previous | cut -d'"' -f2 | cut -d' ' -f2 | cut -d'?' -f1 | sort | uniq -c | sort -n | tail
/>>> 185 /favicon.ico
/>>> 216 /highslide/graphics/zoomout.cur
/>>> 261 /sсript_igra.php
/>>> 268 /sсript_mech.php
/>>> 274 /sсript_all.php
/>>> 335 /sсript_sport.php
/>>> 343 /sсript_child.php
/>>> 421 /
/>>> 427 /news.php
/>>> 1201 /sсript_naduv.php
/>>>
/>>> При этом генерация страницы скриптом потребляет порядка 10 секунд процессорного времени.
/>>>
/>>> username 62906 57.6 0.5 27420 16760 ?? RN 8:36AM 0:09.44 sсript_naduv.php (php-cgi)
/>>>
/>>> Другие скрипты сайта тоже потребляют достаточно много процессорного времени.
/>>>
/>>> username 72192 45.4 0.5 27420 16396 ?? RN 8:36AM 0:06.60 sсript_sport.php (php-cgi)
/>>> username 86791 39.8 0.3 10164 8224 ?? RN 8:36AM 0:05.55 sсript_old.php (php-cgi)
/>>> username 90153 47.4 0.2 8960 7228 ?? RN 8:37AM 0:07.63 sсript_child.php (php-cgi)
/>>> username 96708 51.0 0.4 17620 12408 ?? RN 8:37AM 0:07.69 news.php (php-cgi)
/>>> username 3183 36.9 0.3 14372 10140 ?? RN 8:37AM 0:04.78 sсript_tir.php (php-cgi)
/>>> username 7133 30.3 0.4 19312 13744 ?? RN 8:37AM 0:03.52 sсript_disco.php (php-cgi)
/>>>
/>>> Нормальное потребление процессорного времени скриптами сайта - порядка 0.1-0.3 секунды, а не нескольких секунд.
/>>>
/>>> Системные вызовы процесса генерации скрипта sсript_naduv.php показывают на громадное количество операций смены прав доступа к файлам (зачем такая операция вообще
/>>> производится?) в начале обработки скрипта и на громадное количество операций чтения, которое, по всей видимости, возникают при чтении комментариев из базы данных:
/>>> ...
/>>> 4.966374098 write(4,"i\0\0\0\^Cselect `id`, `comments"...,109) = 109 (0x6d)
/>>> 4.966488919 read(4,"\^A\0\0\^A",4) = 4 (0x4)
/>>> 4.966552895 read(4,"\^F",1) = 1 (0x1)
/>>> 4.966611004 read(4,"N\0\0\^B",4) = 4 (0x4)
/>>> 4.966670790 read(4,"\^Cdef\^Rwwwusernameeru_adm\^Qcu"...,78) = 78 (0x4e)
/>>> 4.966738956 read(4,"Z\0\0\^C",4) = 4 (0x4)
/>>> 4.966794830 read(4,"\^Cdef\^Rwwwusernameeru_adm\^Qcu"...,90) = 90 (0x5a)
/>>> 4.966856012 read(4,"b\0\0\^D",4) = 4 (0x4)
/>>> 4.966917474 read(4,"\^Cdef\^Rwwwusernameeru_adm\^Qcu"...,98) = 98 (0x62)
/>>> 4.966980891 read(4,"Z\0\0\^E",4) = 4 (0x4)
/>>> 4.967041514 read(4,"\^Cdef\^Rwwwusernameeru_adm\^Qcu"...,90) = 90 (0x5a)
/>>> 4.967105490 read(4,"\\\0\0\^F",4) = 4 (0x4)
/>>> 4.967166114 read(4,"\^Cdef\^Rwwwusernameeru_adm\^Qcu"...,92) = 92 (0x5c)
/>>> 4.967229810 read(4,"V\0\0\a",4) = 4 (0x4)
/>>> 4.967290992 read(4,"\^Cdef\^Rwwwusernameeru_adm\^Qcu"...,86) = 86 (0x56)
/>>> 4.967355247 read(4,"\^A\0\0\b",4) = 4 (0x4)
/>>> 4.967415312 read(4,"\M-~",1) = 1 (0x1)
/>>> 4.967485155 read(4,"\^S\0\0\t",4) = 4 (0x4)
/>>> 4.967548293 read(4,"\^A2\0\0\0\fhtml_with_br\0",19) = 19 (0x13)
/>>> 4.967608916 read(4,"\^S\0\0\n",4) = 4 (0x4)
/>>> 4.967668422 read(4,"\^A3\0\0\0\fhtml_with_br\0",19) = 19 (0x13)
/>>> 4.967732398 read(4,"\^S\0\0\v",4) = 4 (0x4)
/>>> 4.967792183 read(4,"\^A4\0\0\0\fhtml_with_br\0",19) = 19 (0x13)
/>>> 4.967848057 read(4,"\^S\0\0\f",4) = 4 (0x4)
/>>> 4.967905608 read(4,"\^A5\0\0\0\fhtml_with_br\0",19) = 19 (0x13)
/>>> 4.967963717 read(4,"\^S\0\0\r",4) = 4 (0x4)
/>>> 4.968021267 read(4,"\^A6\0\0\0\fhtml_with_br\0",19) = 19 (0x13)
/>>> 4.968078538 read(4,"\^S\0\0\^N",4) = 4 (0x4)
/>>> 4.968135809 read(4,"\^A7\0\0\0\fhtml_with_br\0",19) = 19 (0x13)
/>>> 4.968194756 read(4,"\^S\0\0\^O",4) = 4 (0x4)
/>>> 4.968250630 read(4,"\^A8\0\0\0\fhtml_with_br\0",19) = 19 (0x13)
/>>> 4.968309019 read(4,"\^S\0\0\^P",4) = 4 (0x4)
/>>> 4.968366569 read(4,"\^A9\0\0\0\fhtml_with_br\0",19) = 19 (0x13)
/>>> 4.968426354 read(4,"\^T\0\0\^Q",4) = 4 (0x4)
/>>> 4.968481949 read(4,"\^B10\0\0\0\fhtml_with_br\0",20) = 20 (0x14)
/>>> 4.968539779 read(4,"\^T\0\0\^R",4) = 4 (0x4)
/>>> 4.968597608 read(4,"\^B11\0\0\0\fhtml_with_br\0",20) = 20 (0x14)
/>>> ...
/>>>
/>>> Системные вызовы процесса были сняты таким образом и сохранены в файл:
/>>>
/>>> [username@shared ~/www/htdocs]$ while true; do ps aux | grep php-cgi | grep sсript_naduv | awk {'print $2'} | xargs truss -o sсript_naduv.php.txt -d -p ; done
/>>> [username@shared ~/www/htdocs]$ ls -alh sсript_naduv.php.txt
/>>> -rw-r--r-- 1 username username 58M Mar 5 08:45 sсript_naduv.php.txt
/>>>
/>>> Вам необходимо проанализировать этот файл с разработчиками сайта и устранить указанные проблемы.
/>>>
/>> 05.03.2015 14:36 - Username написал(а):
/>> Здравствуйте!
/>> Скачиваем файл. Анализировать с разработчиками не представляется возможным, так
/>> как их давно нет, и связи с ними тоже. Другое дело, что эти же скрипты и работали
/>> все это время и не нагружали настолько сервер, всегда хватало ресурсов. А после
/>> того, как мы оплатили хостинг на год, понеслась проблема с нагрузкой. Данный сайт
/>> плохо оптимизирован. CMS, на которой он устроен, не обновлялась уже много лет. На
/>> данный момент мы делаем другой новый сайт, после него собираемся полностью переделать
/>> проблемный сайт, чтобы он был современным и в плане технической сборки тоже.
/>> Мы постараемся проанализировать данные, которые вы прислали. Будем стараться
/>> исправить проблему, потому что сайт нас кормит, в конце концов...
/>> Но не могли бы вы проанализировать работу сервера до и после начала каждодневной
/>> нагрузки. Мы не меняли ничего на сайте (серьезного) с 2014 года, а нагрузка не
/>> могла начаться просто так, так же исполняя скрипты, как и прежде, это как минимум
/>> странно.
/>>
/> 05.03.2015, 15:10, "Support Team":
/> Здравствуйте!
/>
/> Сервер работает в штатном режиме и его конфигурация и настройки не обновлялись. Также никакие обновления сервера не могли привести к такому эффекту.
/>
/> Нагрузка могла расти постепенно: учитывая, что изменяются права доступа к множеству файлов, их количество будет влиять на итоговый результат, то есть на результат влияет
/> банально наполнение сайта;
/>
/> Нагрузка могла вырасти скачком: учитывая, что производится считывание огромного количества информации из базы данных, причем в этом процессе фигурирует слово
/> "Комментарии", речь может идти об атаке на сайт и создании большого числа спам-комментариев на сайте в различных формах (гостевая книга, комментарии, отзывы и так
/> далее), что привело к дальнейшему затруднению в работе сайта.
/>
/> Также речь может идти о взломе сайта и об изменении его кода, но на наш взгляд были бы иные последствия в виде лишних страниц на сайте, рассылке спама, работе посторонних
/> скриптов - такого сейчас не наблюдается.
/>
/> В любом случае сейчас скрипт в ходе генерации одной страницы совершает порядка 900 тысяч действий, это связано только с кодом и это никак не может быть
/> связано с сервером: в вывод системных вызовов не успела попасть инициализация обработчика PHP, поскольку в штатном режиме она занимает крайне мало времени. Все действия, что
/> производятся при генерации страницы и тратят ресурсы процессора - производятся обработчиком согласно найденному в скриптах коду и никак не связаны с серверным настройками.
/>
Здравствуйте!
После разговоров с вами и проделанных манипуляций, решили нанять фрилансера для
оптимизации кода сайта, чтобы наконец решить проблему нагрузки.
Спасибо за проявленное терпение. Работоспособность сайта для нас первоочередная задача.
/>>> Здравствуйте!
/>>>
/>>> Действительно, нагрузка на сервер не снизилась. В таком случае требуется проверка скриптов Вашего сайта с помощью его разработчика.
/>>>
/>>> В частности, вчера произведено порядка 1200 запросов к скрипту sсript_naduv.php:
/>>>
/>>> [username@shared ~/logs]$ cat custom_log.previous | cut -d'"' -f2 | cut -d' ' -f2 | cut -d'?' -f1 | sort | uniq -c | sort -n | tail
/>>> 185 /favicon.ico
/>>> 216 /highslide/graphics/zoomout.cur
/>>> 261 /sсript_igra.php
/>>> 268 /sсript_mech.php
/>>> 274 /sсript_all.php
/>>> 335 /sсript_sport.php
/>>> 343 /sсript_child.php
/>>> 421 /
/>>> 427 /news.php
/>>> 1201 /sсript_naduv.php
/>>>
/>>> При этом генерация страницы скриптом потребляет порядка 10 секунд процессорного времени.
/>>>
/>>> username 62906 57.6 0.5 27420 16760 ?? RN 8:36AM 0:09.44 sсript_naduv.php (php-cgi)
/>>>
/>>> Другие скрипты сайта тоже потребляют достаточно много процессорного времени.
/>>>
/>>> username 72192 45.4 0.5 27420 16396 ?? RN 8:36AM 0:06.60 sсript_sport.php (php-cgi)
/>>> username 86791 39.8 0.3 10164 8224 ?? RN 8:36AM 0:05.55 sсript_old.php (php-cgi)
/>>> username 90153 47.4 0.2 8960 7228 ?? RN 8:37AM 0:07.63 sсript_child.php (php-cgi)
/>>> username 96708 51.0 0.4 17620 12408 ?? RN 8:37AM 0:07.69 news.php (php-cgi)
/>>> username 3183 36.9 0.3 14372 10140 ?? RN 8:37AM 0:04.78 sсript_tir.php (php-cgi)
/>>> username 7133 30.3 0.4 19312 13744 ?? RN 8:37AM 0:03.52 sсript_disco.php (php-cgi)
/>>>
/>>> Нормальное потребление процессорного времени скриптами сайта - порядка 0.1-0.3 секунды, а не нескольких секунд.
/>>>
/>>> Системные вызовы процесса генерации скрипта sсript_naduv.php показывают на громадное количество операций смены прав доступа к файлам (зачем такая операция вообще
/>>> производится?) в начале обработки скрипта и на громадное количество операций чтения, которое, по всей видимости, возникают при чтении комментариев из базы данных:
/>>> ...
/>>> 4.966374098 write(4,"i\0\0\0\^Cselect `id`, `comments"...,109) = 109 (0x6d)
/>>> 4.966488919 read(4,"\^A\0\0\^A",4) = 4 (0x4)
/>>> 4.966552895 read(4,"\^F",1) = 1 (0x1)
/>>> 4.966611004 read(4,"N\0\0\^B",4) = 4 (0x4)
/>>> 4.966670790 read(4,"\^Cdef\^Rwwwusernameeru_adm\^Qcu"...,78) = 78 (0x4e)
/>>> 4.966738956 read(4,"Z\0\0\^C",4) = 4 (0x4)
/>>> 4.966794830 read(4,"\^Cdef\^Rwwwusernameeru_adm\^Qcu"...,90) = 90 (0x5a)
/>>> 4.966856012 read(4,"b\0\0\^D",4) = 4 (0x4)
/>>> 4.966917474 read(4,"\^Cdef\^Rwwwusernameeru_adm\^Qcu"...,98) = 98 (0x62)
/>>> 4.966980891 read(4,"Z\0\0\^E",4) = 4 (0x4)
/>>> 4.967041514 read(4,"\^Cdef\^Rwwwusernameeru_adm\^Qcu"...,90) = 90 (0x5a)
/>>> 4.967105490 read(4,"\\\0\0\^F",4) = 4 (0x4)
/>>> 4.967166114 read(4,"\^Cdef\^Rwwwusernameeru_adm\^Qcu"...,92) = 92 (0x5c)
/>>> 4.967229810 read(4,"V\0\0\a",4) = 4 (0x4)
/>>> 4.967290992 read(4,"\^Cdef\^Rwwwusernameeru_adm\^Qcu"...,86) = 86 (0x56)
/>>> 4.967355247 read(4,"\^A\0\0\b",4) = 4 (0x4)
/>>> 4.967415312 read(4,"\M-~",1) = 1 (0x1)
/>>> 4.967485155 read(4,"\^S\0\0\t",4) = 4 (0x4)
/>>> 4.967548293 read(4,"\^A2\0\0\0\fhtml_with_br\0",19) = 19 (0x13)
/>>> 4.967608916 read(4,"\^S\0\0\n",4) = 4 (0x4)
/>>> 4.967668422 read(4,"\^A3\0\0\0\fhtml_with_br\0",19) = 19 (0x13)
/>>> 4.967732398 read(4,"\^S\0\0\v",4) = 4 (0x4)
/>>> 4.967792183 read(4,"\^A4\0\0\0\fhtml_with_br\0",19) = 19 (0x13)
/>>> 4.967848057 read(4,"\^S\0\0\f",4) = 4 (0x4)
/>>> 4.967905608 read(4,"\^A5\0\0\0\fhtml_with_br\0",19) = 19 (0x13)
/>>> 4.967963717 read(4,"\^S\0\0\r",4) = 4 (0x4)
/>>> 4.968021267 read(4,"\^A6\0\0\0\fhtml_with_br\0",19) = 19 (0x13)
/>>> 4.968078538 read(4,"\^S\0\0\^N",4) = 4 (0x4)
/>>> 4.968135809 read(4,"\^A7\0\0\0\fhtml_with_br\0",19) = 19 (0x13)
/>>> 4.968194756 read(4,"\^S\0\0\^O",4) = 4 (0x4)
/>>> 4.968250630 read(4,"\^A8\0\0\0\fhtml_with_br\0",19) = 19 (0x13)
/>>> 4.968309019 read(4,"\^S\0\0\^P",4) = 4 (0x4)
/>>> 4.968366569 read(4,"\^A9\0\0\0\fhtml_with_br\0",19) = 19 (0x13)
/>>> 4.968426354 read(4,"\^T\0\0\^Q",4) = 4 (0x4)
/>>> 4.968481949 read(4,"\^B10\0\0\0\fhtml_with_br\0",20) = 20 (0x14)
/>>> 4.968539779 read(4,"\^T\0\0\^R",4) = 4 (0x4)
/>>> 4.968597608 read(4,"\^B11\0\0\0\fhtml_with_br\0",20) = 20 (0x14)
/>>> ...
/>>>
/>>> Системные вызовы процесса были сняты таким образом и сохранены в файл:
/>>>
/>>> [username@shared ~/www/htdocs]$ while true; do ps aux | grep php-cgi | grep sсript_naduv | awk {'print $2'} | xargs truss -o sсript_naduv.php.txt -d -p ; done
/>>> [username@shared ~/www/htdocs]$ ls -alh sсript_naduv.php.txt
/>>> -rw-r--r-- 1 username username 58M Mar 5 08:45 sсript_naduv.php.txt
/>>>
/>>> Вам необходимо проанализировать этот файл с разработчиками сайта и устранить указанные проблемы.
/>>>
/>> 05.03.2015 14:36 - Username написал(а):
/>> Здравствуйте!
/>> Скачиваем файл. Анализировать с разработчиками не представляется возможным, так
/>> как их давно нет, и связи с ними тоже. Другое дело, что эти же скрипты и работали
/>> все это время и не нагружали настолько сервер, всегда хватало ресурсов. А после
/>> того, как мы оплатили хостинг на год, понеслась проблема с нагрузкой. Данный сайт
/>> плохо оптимизирован. CMS, на которой он устроен, не обновлялась уже много лет. На
/>> данный момент мы делаем другой новый сайт, после него собираемся полностью переделать
/>> проблемный сайт, чтобы он был современным и в плане технической сборки тоже.
/>> Мы постараемся проанализировать данные, которые вы прислали. Будем стараться
/>> исправить проблему, потому что сайт нас кормит, в конце концов...
/>> Но не могли бы вы проанализировать работу сервера до и после начала каждодневной
/>> нагрузки. Мы не меняли ничего на сайте (серьезного) с 2014 года, а нагрузка не
/>> могла начаться просто так, так же исполняя скрипты, как и прежде, это как минимум
/>> странно.
/>>
/> 05.03.2015, 15:10, "Support Team":
/> Здравствуйте!
/>
/> Сервер работает в штатном режиме и его конфигурация и настройки не обновлялись. Также никакие обновления сервера не могли привести к такому эффекту.
/>
/> Нагрузка могла расти постепенно: учитывая, что изменяются права доступа к множеству файлов, их количество будет влиять на итоговый результат, то есть на результат влияет
/> банально наполнение сайта;
/>
/> Нагрузка могла вырасти скачком: учитывая, что производится считывание огромного количества информации из базы данных, причем в этом процессе фигурирует слово
/> "Комментарии", речь может идти об атаке на сайт и создании большого числа спам-комментариев на сайте в различных формах (гостевая книга, комментарии, отзывы и так
/> далее), что привело к дальнейшему затруднению в работе сайта.
/>
/> Также речь может идти о взломе сайта и об изменении его кода, но на наш взгляд были бы иные последствия в виде лишних страниц на сайте, рассылке спама, работе посторонних
/> скриптов - такого сейчас не наблюдается.
/>
/> В любом случае сейчас скрипт в ходе генерации одной страницы совершает порядка 900 тысяч действий, это связано только с кодом и это никак не может быть
/> связано с сервером: в вывод системных вызовов не успела попасть инициализация обработчика PHP, поскольку в штатном режиме она занимает крайне мало времени. Все действия, что
/> производятся при генерации страницы и тратят ресурсы процессора - производятся обработчиком согласно найденному в скриптах коду и никак не связаны с серверным настройками.
/>
Здравствуйте!
После разговоров с вами и проделанных манипуляций, решили нанять фрилансера для
оптимизации кода сайта, чтобы наконец решить проблему нагрузки.
Спасибо за проявленное терпение. Работоспособность сайта для нас первоочередная задача.
-
-
06.03.2015 в 12:38-
-
06.03.2015 в 12:41Но тут скорее офигевание было после того, как я глянул результаты strace