LINUX.ORG.RU
решено ФорумAdmin

Сервер под нагрузкой поисковиков падает

 , , ,


0

2

Поисковики нагружают сервер. Обычно используется около 7-8Гб оперативы, в загруженном состоянии занимается 14Гб из 24. При Load Average 80. Система активно юзает свап. Через некоторое время такая нагрузка прекращается, но всё же, очень сильно виснет система.

Куда рыть? Может в апаче прописывать что-то? Или понижать приоритет свапа? Такое не первый раз, вроде ещё системе хватает 10Гб оперативы, но оно почему-то в свап уходит, Load Average вообще зашкаливает.

★★★★★

Гугли параметр vm.swappines, но вообще очень странно, что поисковые боты так нагружают систему.

trofk ★★★
()

Load Average вообще зашкаливает.

Включай atop и смотри откуда ноги растут. Может это диск не справляется.

xtraeft ★★☆☆
()
Ответ на: комментарий от goingUp

В htop'е посмотрел. Забивается оператива примерно на 14Гб из 24 и дальше опратива стоит на месте, а значение свапа изменяется.

Amet13 ★★★★★
() автор топика
Ответ на: комментарий от trofk

А вообще может это не от поисковиков? Загрузка не свербольшая для такого железа. Может в апаче или мускуле что-то неправильно прописано? Какое-то значение...

Amet13 ★★★★★
() автор топика
Ответ на: комментарий от Amet13

my.cnf

...
key_buffer_size		= 2048M
max-connect_errors = 50
table_open_cache = 36288
innodb_buffer_pool_size = 2048M
open_files_limit = 18200
...
apache2.conf
Timeout 300
KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 5
<IfModule mpm_prefork_module>
    StartServers          5
    MinSpareServers       5
    MaxSpareServers      10
    MaxClients          256
    MaxRequestsPerChild  3000
</IfModule>
...

Amet13 ★★★★★
() автор топика
Ответ на: комментарий от Amet13

Вот сейчас например, всё те же боты сканируют и всё ок. А в тот раз, бац и всё, система перегружена.

Amet13 ★★★★★
() автор топика

Какие ещё идеи есть?

Возможно проблема совсем в другом.

По факту забивается RAM до определённого значения и активно юзается свап.

Amet13 ★★★★★
() автор топика
Ответ на: комментарий от Amet13

Возможно проблема совсем в другом.

Дисковую нагрузку ты решил не смотреть? Ок.
Кстати, для приличия на фронтенд надо поставить nginx.

xtraeft ★★☆☆
()
Ответ на: комментарий от xtraeft

Кстати, для приличия на фронтенд надо поставить nginx.

Удваиваю, даже утраиваю этого господина

dvrts ★★★
()
Ответ на: комментарий от xtraeft

Есть nginx. Ничего подозрительного я не заметил.

Судя по графикам в munin нагрузка на диск адовая.

Не ведутся ли какие-то логи по нагрузке на диск?

Amet13 ★★★★★
() автор топика

А кто-нибудь вообще пробовал тюнить хотья что-то для производительности? Или изначально решили просто поставить железо покруче, а на всё остальное забить?

Как именно веб-сервер устроен? На чём сайт крутится?

frozen_twilight ★★
()
Ответ на: комментарий от xtraeft

Сейчас нагрузки особой нет.

Смотрю iotop, понемногу пишут/читают процессы php и mysql.

iostat:

root@host:~# iostat
Linux 3.2.0-4-amd64 (host.ru) 	28.08.2014 	_x86_64_	(8 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          10,09    0,00    3,96    3,73    0,00   82,23

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
cciss/c0d0      236,36      1602,29       905,56    7745395    4377416

Судя по atop, основная нагрузка на диск от mysql:

rdisk | wrdisk | wcancl | dsk | cmd
3.2G  | 343G   | 340G   | 98% | mysql

Amet13 ★★★★★
() автор топика
Ответ на: комментарий от frozen_twilight

А кто-нибудь вообще пробовал тюнить хотья что-то для производительности?

Да, тюнил. апач+нгинкс+мускуль+пхп тюнил.

Как именно веб-сервер устроен? На чём сайт крутится?

ISPmanager. Сайтов много, в основном на джумла.

Amet13 ★★★★★
() автор топика
Ответ на: комментарий от Amet13

Железо, если что:

product: ProLiant DL160 G5 ()
product: Intel(R) Xeon(R) CPU           E5430  @ 2.66GHz
slot: Processor 0 Internal L2 Cache
   size: 12MiB
memory size: 24GiB
lshw, к сожалению, кроме dvdrom дисков не обнаруживает.

Amet13 ★★★★★
() автор топика

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

prizident ★★★★★
()
Ответ на: комментарий от hidden_4003

Я не совсем понял рейд там или нет. Вроде как один. Не рейд.

root@host:~# hwinfo --disk
35: None 00.0: 10600 Disk                                       
  [Created at block.243]
  Unique ID: ZJ2m.Fxp0d3BezAE
  Parent ID: x1VA.DXZOmjGcDK6
  SysFS ID: /class/block/cciss!c0d0
  SysFS BusID: c0d0
  SysFS Device Link: /devices/pci0000:00/0000:00:05.0/0000:09:00.0/cciss0/c0d0
  Hardware Class: disk
  Model: "Disk"
  Driver: "cciss"
  Driver Modules: "cciss"
  Device File: /dev/cciss/c0d0
  Device Files: /dev/cciss/c0d0, /dev/disk/by-id/cciss-3600508b1001052395358413343360007, /dev/disk/by-id/wwn-0x600508b1001052395358413343360007, /dev/disk/by-path/pci-0000:09:00.0
  Device Number: block 104:0-104:15
  BIOS id: 0x80
  Geometry (Logical): CHS 107724/255/32
  Size: 879032432 sectors a 512 bytes
  Config Status: cfg=new, avail=yes, need=no, active=unknown
  Attached to: #28 (RAID bus controller)

Amet13 ★★★★★
() автор топика
Ответ на: комментарий от prizident

Неужели из-за небольшого увеличения нагрузки, может так сильно тормозить?

Amet13 ★★★★★
() автор топика

imho в job с такой базовой диагностикой: ни информации по rss, vms по процессам, ни вменяемого описания конфигурации какой-либо подсистемы, ни вообще описание окружения с хотя бы схематическим параметризированием.

man iostat, кстати, тоже почитай, чтоб предоставить iops, а не килобайты в секунду.

Хотя на вскидку итак понятно, что mysql упирается в io, потому что читает и пишет на диск постоянно.

Ip0 ★★★★
()
Последнее исправление: Ip0 (всего исправлений: 1)
Ответ на: комментарий от Ip0

man iostat, кстати, тоже почитай, чтоб предоставить iops, а не килобайты в секунду.

Читал, не нашёл в мане такого.

ни информации по rss, vms по процессам, ни вменяемого описания конфигурации какой-либо подсистемы, ни вообще описание окружения с хотя бы схематическим параметризированием.

Пока нет такого опыта как у Вас, поэтому и спрашиваю.

Внимательно выслушаю любые предложения и постараюсь предоставить все необходимые для диагностики данные.

Amet13 ★★★★★
() автор топика

Давайте представим такое. Ситуация опять повторяется.

Большая нагрузка на диск, система грузит оперативу, LA зашкаливает, система уходит в свап.

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

(Это мне инструкция на будущее)

Спасибо.

До этого, по всей видимости собирал неправильные данные и не смог вовремя посмотреть нужные утилиты.

Amet13 ★★★★★
() автор топика
Ответ на: комментарий от Amet13

Если мое предположение про mysql верно, то для начала хотелось бы взглянуть на вывод:

iostat -x 2 6

В целом, в идеальном сетапе чтения с диска быть не должно/должно быть минимальным. Если для организации идеального сетапа памяти не достаточно, то в общем случае поможет поднятие производительности дисковой подсистемы (ssd, raid0), однако на вскидку это видится менее эффективным и более дорогим вариантом. Хотя опять же без представления конкретики окружения (сколько баз, сколько клиентов, каков объем,какой движок базы, что как с чем работает, схема использования nginx, apache, php) всё это весьма для сферического типового случая в вакуме.

Зачем в этой схеме вообще нужен swap — представить себе не могу. Если предположить его гипотетическое использование — значит уже в проектировании что-то пошло не так.

Ip0 ★★★★
()
Последнее исправление: Ip0 (всего исправлений: 2)
Ответ на: комментарий от Ip0

С нуля проектировал не я, приходится админить уже то что есть. В основе лежит панель ISPmanager. Я бы наверное сделал немного по-другому, если б делал сам с нуля.

Предположим, что в аппаратной части расширение невозможно. Допустим, что это действительно мускул грузит дисковую подсистему. Что я должен сделать со своей стороны относительно мускуля? Какие параметры оптимизировать? Я в своё время тюнил его в основном по рекомендациям mysqltuner.pl.

Некоторые директивы из конфига MySQL я привёл несколькими постами выше (полный конфиг тут).

Вывод iostat в обычном, ненагруженном состоянии:

root@host:~# iostat -x 2 6
Linux 3.2.0-4-amd64 (host.ru) 	29.08.2014 	_x86_64_	(8 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          11,31    0,00    3,31    1,72    0,00   83,66

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
cciss/c0d0        1,29    29,81   98,87   21,03  2425,14   582,36    50,17     0,68    5,64    2,51   20,37   1,26  15,08

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          10,01    0,00    1,13    0,00    0,00   88,87

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
cciss/c0d0        0,00    29,00    0,00   58,00     0,00  1468,00    50,62     0,00    0,07    0,00    0,07   0,07   0,40

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0,31    0,00    0,06    0,06    0,00   99,56

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
cciss/c0d0        0,00    47,00    4,50    3,50    18,00   204,00    55,50     0,03    4,00    7,11    0,00   0,50   0,40

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0,06    0,00    0,06    0,00    0,00   99,87

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
cciss/c0d0        0,00    26,50    0,00    8,50     0,00   140,00    32,94     0,00    0,00    0,00    0,00   0,00   0,00

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           1,81    0,00    0,19    0,00    0,00   98,00

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
cciss/c0d0        0,00     0,00    0,00    4,00     0,00    30,00    15,00     0,00    0,00    0,00    0,00   0,00   0,00

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           3,88    0,00    0,13    0,00    0,00   96,00

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
cciss/c0d0        0,00    26,00    0,00    4,50     0,00   130,00    57,78     0,00    0,44    0,00    0,44   0,44   0,20
Пока, по рекомендациям в треде я сменил значение vmswapiness, (может вообще стоит свап отключить?) и немного освоился с atop, iotop, iostat).

Спасибо за помощь.

Amet13 ★★★★★
() автор топика

А какое поделие на этом сервере крутится, что его с такими чудовищными ресурсами нагибает поисковик?

anonymous
()
Ответ на: комментарий от anonymous

Поделие чего? Конкретнее можно? Сайтов 100-200, в основном на джумле. апач+нгинкс+мускуль+пхп в cgi моде. На базе ISPmanager. Не думаю, что именно поисковик его нагибает, бывает что поисковик шестерит и всё норм, а бывает, как я описал всё выше. Вот я и хочу разобраться, почему оно так случается и что нужно сделать для того, чтобы чтобы такого не повторялось.

Amet13 ★★★★★
() автор топика
Последнее исправление: Amet13 (всего исправлений: 1)
Ответ на: комментарий от Amet13

Судя по atop, основная нагрузка на диск от mysql

Так везде на среднестатистических xAMP конфигах и бывает зачастую. Большая часть данных то читается и пишется СУБД.

Если MySQL не настроен откровенно криво, например, задан лимит в несколько сотен подключений, то он сильно выделяться на фоне прочего не должен.

Лучше смотри потребление памяти. Поскольку память -> своп -> диск -> запредельный LA.

frozen_twilight ★★
()
Последнее исправление: frozen_twilight (всего исправлений: 2)
Ответ на: комментарий от frozen_twilight

Что можно сказать об этом конфиге? Есть ли в нём что-то откровенно кривое? Мне кажется это из-за кривой настройки мускуля (настраивал на основе дефолтного конфига и рекомендация mysqltuner и tuning-primer. Незначительные по моему мнению директивы я сюда не пишу.

root@host:/tmp# cat /etc/mysql/my.cnf | grep -v "^#"
key_buffer_size		= 2048M

max_allowed_packet	= 16M
thread_stack		= 192K
thread_cache_size       = 8
max-connect_errors = 50

max_connections = 256

table_cache		= 1024
wait_timeout		= 120
interactive_timeout	= 100
connect_timeout		= 120
query_cache_limit = 16M

query_cache_size        = 128M

join_buffer_size = 8M
read_buffer_size = 2M
sort_buffer_size = 256K

tmp_table_size = 512M
max_heap_table_size = 512M

table_open_cache = 16384

table_definition_cache = 512

innodb_buffer_pool_size = 2048M

open_files_limit = 18200

Amet13 ★★★★★
() автор топика
Ответ на: комментарий от Amet13

Насчёт потребления памяти, я уверен, что именно мускуль потребляет больше всего памяти и именно он нагружает систему.

Amet13 ★★★★★
() автор топика
Ответ на: комментарий от Amet13

возможно стоит начать с того, что вернуться к дефолтным (не таким завышенным значениям параметров) настройкам в my.cnf и посмотреть как оно будет.

nerve ★★
()
Ответ на: комментарий от Amet13

Если уверены что проблема в мускуле - попробуйте запустить MySQL Tuning Primer и посмотреть его рекомендации.
Так же во время «аномальной» нагрузки, не помешает глянуть

mysql> show processlist;
посмотрите что именно создает нагрузку(какая база, запрос).

zaharov
()
Ответ на: комментарий от zaharov

Ага, мне подсказали. что его надо смотреть. Я на всякий случай скрипт сделал, чтобы каждую минуту чекал процесслист и записывал в файл.

Значит во время нагрузки план моих действий таков:

1. Я смотрю atop, скорее всего там будет показана бешеная нагрузка от mysql

2. Я смотрю show processlist;

3. ??? Что я должен делать дальше? Отключать сайт на который идёт нагрузка , через ISPmanager? Или останавливать процессы MySQL?

Amet13 ★★★★★
() автор топика
Ответ на: комментарий от Amet13

отключить один сайт, имхо, предпочтительней чем останавливать мускул полностью.
А дальше глядеть что за запрос\запросы валят мускул и что с ними можно сделать.

zaharov
()
Ответ на: комментарий от zaharov

Действительно ли может быть такой треш всего лишь от одного запроса? Или скорее всего их несколько?

Amet13 ★★★★★
() автор топика
Ответ на: комментарий от Komintern

Бруты я отсеиваю самопальным скриптом.

Amet13 ★★★★★
() автор топика

В выявлении плохой базы помог мониторинг processlist'а и утилита mk-query-digest.

Спасибо за помощь всем.

Amet13 ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.