Главная » Форум » Gentoo Linux » Системное администрирование

Виснет сервер HP, помогите поставить диагноз

stailer 19 октября, 2010 - 10:00

Переодически (1-2 в сутки), при непонятных обстоятельствах, виснет сервер.
Виснет не намертво, консоль доступна, но не всё выполняется. Например rc-status виснет (при запуске подвешивает терминал), с bash-скрипами такая же история. Демоны не реагируют ни на что (даже на kill). htop показывает полную загрузку памяти, но при этом своп полностью свободен.
На сервере крутятся mysql, nginx, php(fcgi), zabbix.
/var/log/message

‹ [SOLVED] Посоветуйте более производительные сетевые карты. [Solved] HP Color cp1215 HOWOTO or Gentoo vs Others Linux's ›
»

Осторожно, по пруфу мегабайты

Автор slepnoga, дата создания 19 октября, 2010 - 10:35.

Осторожно, по пруфу мегабайты логов ( а конкретно 102205 строк О_О)- - ТС решил что много не мало ?

—

Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)

»

проблемы с файловой системой

Автор leryc, дата создания 19 октября, 2010 - 10:55.

проблемы с файловой системой и\или наличием свободного места в разделе(ах) ?

stailer написал(а):
Демоны не реагируют ни на что (даже на kill).

—

что-то добрый я сегодня ....

»

Filesystem Size

Автор stailer, дата создания 19 октября, 2010 - 11:31.

Filesystem Size Used Avail Use% Mounted on
/dev/cciss/c0d0p1 2.0G 164M 1.9G 9% /
udev 10M 200K 9.9M 2% /dev
/dev/cciss/c0d0p5 1012M 1.3M 960M 1% /tmp
/dev/cciss/c0d0p6 20G 3.3G 17G 17% /usr
/dev/cciss/c0d0p7 110G 44M 110G 1% /home
/dev/cciss/c0d1p1 137G 35G 102G 26% /var

/tmp - ext2
остальные xfs

Проблемма возникает только когда запущены все нужные демоны.
Когда mysql, php, nginx и zabbix не запущены сервак работает как часы.

»

Смею предположить, что

Автор Han, дата создания 19 октября, 2010 - 13:34.

Смею предположить, что проблема не в работе оборудования/системы, как таковой. Проблема, скорей всего, в связке nginx+mysql. Можно увидеть ФРАГМЕНТЫ логов error.log для mysql и nginx ?
а заодно уж и их конфиги....

»

/etc/nginx/nginx.conf/var/lo

Автор stailer, дата создания 19 октября, 2010 - 15:04.

В этот раз не такие большие =)

/etc/nginx/nginx.conf
/var/log/nginx/error_log
/etc/mysql/my.cnf
/var/log/mysql/mysqld.err

»

так это и понятно ,

Автор leryc, дата создания 19 октября, 2010 - 15:31.

так это и понятно , что

stailer написал(а):
Проблемма возникает только когда запущены все нужные демоны.
Когда mysql, php, nginx и zabbix не запущены сервак работает как часы.

но, на мой взгляд, /tmp мало место выделено, если сервер работает под нагрузкой

ключевая фраза

демоны не реагируют ни на что (даже на kill).

это случается когда
- нет места на диске
- нет места в памяти
- открыто слишком много дескрипторов
- зависание файловой системы
- (и\или) корень /, /tmp, /var, /dev, /proc в результате сбоя перемонтированы в режиме "только чтение"

ключевая фраза

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

наводит на мысль, что своп
не размечен \ не подключен \ не работает

возможно, что память забита на 101% и не удается запустить новый процесс (в том числе и kill)

свободное место на диске надо смотреть в момент "зависания"

например и у меня в связке havp+clamav в /tmp такая туева куча файловых дескрипторов, что mc впадает в ступор минут на 10-15 при попытке войти в директорию

после перезагрузки - естественно всё ддевственно чисто ;)

ps
попробуйте сделать симлинк /tmp в /var/tmp - будет ли наблюдаться "зависание" ?

—

что-то добрый я сегодня ....

»

В момент зависания: radom ~ #

Автор stailer, дата создания 20 октября, 2010 - 11:38.

В момент зависания:

radom ~ # df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/cciss/c0d0p1     2.0G  164M  1.9G   9% /
udev                   10M  200K  9.9M   2% /dev
/dev/cciss/c0d0p5    1012M  1.4M  960M   1% /tmp
/dev/cciss/c0d0p6      20G  3.3G   17G  17% /usr
/dev/cciss/c0d0p7     110G   44M  110G   1% /home
/dev/cciss/c0d1p1     137G   36G  101G  27% /var

radom ~ # ls -al /tmp
total 36
drwxrwxrwt  5 root   root    4096 Oct 20 11:48 .
drwxr-xr-x 18 root   root    4096 Oct 18 11:50 ..
drwxrwxrwt  2 root   root    4096 Oct 20 02:59 .ICE-unix
drwxrwxrwt  2 root   root    4096 Oct 20 02:59 .X11-unix
drwx------  2 root   root   16384 Sep 21 15:15 lost+found
-rw-rw-r--  1 zabbix zabbix   451 Oct 20 11:48 zabbix_server_22170.pinger

Свежие (короткие) логи:
/var/log/messages
/var/log/nginx/error_log
/var/log/mysql/mysqld.err

Я проводил тест с помощью app-benchmarks/stress-1.0.1
В течении часа загрузка на все процы была 100%, на память 100%, свап %98~%99 (при 100% stress вырубался).
Во время теста сервак вёл себя пристойно. Никаких признаков зависания небыло.

Так же проверил память memtest'ом, там всё в порядке.

leryc написал(а):
- (и\или) корень /, /tmp, /var, /dev, /proc в результате сбоя перемонтированы в режиме "только чтение"

Это забыл посмотреть. Буду ждать следующего зависания.

»

зависания происходят под

Автор leryc, дата создания 20 октября, 2010 - 14:25.

зависания происходят под реальной нагрузкой или только на stress'е ?
может 4G свопа маловато будет? сколько оперативной?
я как-то проверял -2гб свопа хватило на ~1100 открытых вкладок оперы
сколько у вас макс. коннектов в пик нагрузки?

—

что-то добрый я сегодня ....

»

leryc написал(а): зависания

Автор stailer, дата создания 20 октября, 2010 - 15:55.
leryc написал(а):
зависания происходят под реальной нагрузкой или только на stress'е ?

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

leryc написал(а):
может 4G свопа маловато будет? сколько оперативной?

Памяти 4Gb.

leryc написал(а):
сколько у вас макс. коннектов в пик нагрузки?

Примерно 20000 проверок в минуту по ICMP и SNMP.
Пиков как таковых нет, так как забикс распределяет все проверки.
По HTTP 2-3 клиета, у которых страница с состоянием тригеров обновляется раз в минуту.

Наблюдаю сегодня за серваком весь день:
1 - мускул отжирает примерно 60% памяти, и больше не растёт.
2 - свап практически не используется (150~180 Mb).

»

htop показывает полную

Автор slepnoga, дата создания 20 октября, 2010 - 16:17.
htop показывает полную загрузку памяти, но при этом своп полностью свободен.

Примерно 20000 проверок в минуту по ICMP и SNMP.

Что с софтирками и памятью ядра? в часности сколько сжирает сетевая, какие сетевеые карты ?

—

Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)

»

slepnoga написал(а): Что с

Автор stailer, дата создания 21 октября, 2010 - 06:00.
slepnoga написал(а):
Что с софтирками и памятью ядра? в часности сколько сжирает сетевая, ...

Как это можно посмотреть?

slepnoga написал(а):
какие сетевеые карты ?

4 штуки Broadcom Corporation NetXtreme II BCM5709 Gigabit Ethernet
Работает только одна.

»

из вашего messages из первого

Автор bes.internal, дата создания 22 октября, 2010 - 01:11.

из вашего messages из первого поста, пояснили бы что за нагрузка-то такая в 20000 обращений в минуту

Oct 12 09:29:11 radom kernel: nf_conntrack: table full, dropping packet.
Oct 12 09:29:11 radom kernel: nf_conntrack: table full, dropping packet.
»

а зачем nginx было ставить

Автор leryc, дата создания 20 октября, 2010 - 16:26.

а зачем nginx было ставить если

По HTTP 2-3 клиета, у которых страница с состоянием тригеров обновляется раз в минуту.

?

Примерно 20000 проверок в минуту по ICMP и SNMP.

это ~300-400 в сек
информация об этом вносится мускул?
и вообще - кто грузит\напрягает мускул и какими запросами?
судя по двум предыдущим постам - мускул "зашивался"....
почему?

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

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

с забиксом не работал - его слабых мест не знаю...

а так - нужно ждать (не провоцируя) очередного зависания...

—

что-то добрый я сегодня ....

»

leryc написал(а): а зачем

Автор stailer, дата создания 21 октября, 2010 - 06:53.
leryc написал(а):
а зачем nginx было ставить

Ставить ради 2х - 3х клиентов апач было както не разумно, поэтому выбирал из nginx и lighttpd.
Не помню по какой причине, но выбор остановился на nginx.

leryc написал(а):
это ~300-400 в сек
информация об этом вносится мускул?
и вообще - кто грузит\напрягает мускул и какими запросами?
судя по двум предыдущим постам - мускул "зашивался"....
почему?

Информация о каждой проверке вносится в мускул. Забикс какраз и грузит его.
Запросы должны быть не сложные, простая выборка/вставка, без регулярных вырожений.
Какими именно запросами сказать не могу, так как не сам забикс писал =)

leryc написал(а):
ну и как вариант - сетевуха не справляется с нагрузкой?

Как это посмотреть можно?

leryc написал(а):
и еще - похоже у вас bind запущен - может выделить ему побольше памяти под кэш? это в свою очередь немного разгрузит сетевуху.

bind не стоит. DNS'ка отдельно крутится на другой машине.

leryc написал(а):
а так - нужно ждать (не провоцируя) очередного зависания...

Долго ждать не пришлось
ps ax -o pid,ppid,cputime,pcpu,pmem,vsz,rss,args

»

пока далеко не улетело - еще

Автор leryc, дата создания 21 октября, 2010 - 06:58.

пока далеко не улетело - еще раз mysql.err покажите

—

что-то добрый я сегодня ....

»

/var/log/mysql/mysqld.err

Автор stailer, дата создания 21 октября, 2010 - 07:55.

/var/log/mysql/mysqld.err

»

не в тему , но если там

Автор slepnoga, дата создания 21 октября, 2010 - 08:28.

не в тему , но если там только lamp и заббикс - то в ядре много лишнего

—

Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)

»

я согласен со slepnoga, что

Автор leryc, дата создания 21 октября, 2010 - 14:37.

я согласен со slepnoga, что много лишнего для такого сервака.....

посмотреть ifconfig (для начала) на предмет err\bad пакетов .....

разбираться почему падает мускул....

путей тут много...

- уменьшение времени на lock на файлы
- увеличение буферов
- оптимизировать кол-во забикс-процессов и таймауты обработки

спросить у гугла нечто "оптимизация скорости обработки тюнинг мускул mysql тонкая настройка" .....
с год назад попадалась хорошая статья - но там всё так заумно про настройку внутренностей, что я отложил на "потом" ибо до таких нагрузок пока не дорос...

попадалось замечание, что INNODB не дружит со скорострельностью.....

гугление по теме заббикс позволило подсмотреть один из "типовых" запросов в базу - а там оператор JOIN, что естественно создает нагрузку на внутренности мускула....

может имеет смысл перейти на postgresql ?

зы.

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

—

что-то добрый я сегодня ....

»

Если включить binarylog то

Автор myaucher, дата создания 21 октября, 2010 - 18:20.

Если включить binarylog то это только ускорит очередной сбой сервера т.к. заббикс довольно сильно напрягает mysql - а тут еще и на диск начнем писать все запросы в файл.
с чего вы взяли что какая то табличка крашится?
я вижу в ps 8 worker от nginx. зачем?

Добавлю.
Только сейчас увидел что пишется у вас уже binarylog. а зачем?

Еще добавлю вопрос,
почему так много процессов phpfpm? ведь много подъедают у вас ресурсов то они.
Мне кажется имеет смысл отказаться от использования php-fpm, а использовать apache.

»

Мне кажется имеет смысл

Автор slepnoga, дата создания 21 октября, 2010 - 20:39.
Мне кажется имеет смысл отказаться от использования php-fpm, а использовать apache.

+ много. запуск пхп через php-fpm не оправдан ничем, кроме желания увеличить нагрузку на сервак в данном случае

INNODB и скорость - это понятия из разных галактик

—

Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)

»

:)

Автор Agressor, дата создания 22 октября, 2010 - 03:45.

Попробовать так в /etc/sysctl.conf

# Разрешить масштабирование окна TCP
net.ipv4.tcp_window_scaling = 1

# Увеличить максимальный размер буфера TCP
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.core.somaxconn = 512

# Увеличить максимальное значение самонастраиваемого буфера TCP
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216

# Увеличить количество доступных портов
net.ipv4.ip_local_port_range = 1024 65000

# Увеличенное число отслеживаемых соединений
net.ipv4.netfilter.ip_conntrack_max=1548576
»

Настройки просмотра комментариев

Выберите нужный метод показа комментариев и нажмите "Сохранить установки".