LINUX.ORG.RU
ФорумAdmin

syslog -r и проблемы с производительностью


0

0

Здравствуйте!

Есть 70 клиентов, пишуших с помощью syslog информацию на сервер.
И есть сервер, на котором, если включить syslog с возможность принимать сообщения по сети (syslogd -r), замедляет сервер очень.
Объем сообщений небольшой (165Кб/минуту, 10Мб в час).
Симптомы: нет возможности подключиться к другим сервисам системы (ftp,imap), при ssh подключение происходит но после ввода пароля сообщается «Broken pipe», если уже в рамках открытой сессии обычного пользователя выполнить sudo su, то это закончится тоже ничем, под root нельзя запустить top (но если top запустить до запуска syslogd -r, то программа работает нормально). Нагрузка на ЦП 5%.

В /var/log/messages ничего страшного нет.

Если кто-то сталкивался, или может сообщить, как понять, чего не хватает системе, сообщите, пожалуйста. У меня есть предположение, что это как-то связано с UDP, но никаких доказательств нет.
Пробовал увеличивать лимиты в limits.conf, и все-равно результат нулевой.

root@srv20:/home/user# ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 20
file size (blocks, -f) unlimited
pending signals (-i) 16382
max locked memory (kbytes, -l) 2048
max memory size (kbytes, -m) unlimited
open files (-n) 10000
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 65535
cpu time (seconds, -t) unlimited
max user processes (-u) unlimited
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited

root@srv20:/home/user# cat /etc/security/limits.conf | grep syslog
syslog soft nofile 10000
syslog hard nofile 65000
syslog soft nproc 500
syslog hard nproc 512
syslog - stack 65535
syslog - memlock 1024
syslog - priority 5

и я добавил в /etc/sysctl.conf эти линии (надеясь победить проблему):
kernel.max_lock_depth=8192
#TCP TUNING
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 65536 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
net.ipv4.tcp_no_metrics_save = 1
net.ipv4.tcp_moderate_rcvbuf = 1
net.core.netdev_max_backlog = 250

Ответ на: комментарий от ventilator

Да, хватает

Гигабайт 14 свободно, даже своп вообще не используется.

utandr ()

Лимиты вам не должны помочь. Либо у вас очень большой поток сообщений, просто syslog пишет только некоторые и получается 165 кбайт/с, либо проблемы с жестким диском. Syslog пишет только на диск или ещё куда?

Нагрузка на ЦП 5%.

5% чего, user или system? Какой load average?

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

Load average: 1.60 1.93 1.76

Вот данные на текущий момент:
User 7%, System: 0.09-0.6%

Загрузка процессора от syslog почти никак не изменяется.
(user возрастает на 2%, но мне сложно сказать - это от самого syslog или просто так получалось, так как нагрузка, сами понимаете, на рабочем устройстве подвержена изменениям).

Проблемы с жестким диском были раньше (из-за прошивок в жестких дисках), но потом эта проблема решилась перепрошивкой, на всякий случай еще и драйвер aacraid обновили. После чего была куча тестов. К тому же, на этот сервер куча файловых операций чтения-записи производится и без syslog, и куда большего объема. Так что мне кажется, жесткий диск - это не то, куда нужно смотреть: 10Мб/час нагрузка не может быть такой критичной. Но, может быть, есть какие-то лимиты на чтение/запись? Как их посмотреть?

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

utandr ()

Попробуйте, включив subj на уровне iptables забанить все 70 клиентов, включая по одному и смотря на результат.

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

Не знаю, но лимиты, это границы, за которые процессу (пользователю) нельзя выходить. То есть если бы syslog'у чего то не хватало, он бы этого не получал и завершался (постоянно падал), а у вас другая ситуция.

Относительно записи, конечно, 10 Мб/час это мало, но дело в том, что по умолчанию syslog делает 'sync' после каждой записи. В linux'e sync фактически делается не на файл, а на устройство. И если драйвер или НЖМД как то кривовато работает, то постоянный sync (сброс всех дисковых буферов) может привести именно к таким последствиям.

Попробуйте в настройках syslog перед именами файлов добавить минусик '-', чтобы он постоянно не синхал. Да, есть риск не досчитаться логов при краше системы, но вы пока сделайте это временно.

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

Да, я делал перенаправление и в кэш-файл (с «минусиком») и просто в /dev/null, и в pipe (изначально мне как раз в пайп нужно). И результат один - система сильно замедляется.
К тому же другие-то логи пишутся и все хорошо. Впрочем, думаю, действительно нужно обновить драйвер или даже прошивку raid-контроллера.

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