| Странный рост показаний счётчика dcachesize [message #48265] |
Wed, 10 October 2012 11:24  |
kopytov
Messages: 17
Registered: July 2007
Location: Cyprus, Limassol
|
Junior Member |
|
|
Я столкнулся с очень странной проблемой роста параметра dcachesize в одном из контейнеров. Контейнер создан на базе официального образа centos-6-x86_64, поверх которого установлена контрольная панель для управления хост-нодами. В состав контрольной панели входят скрипты, которые запускаются по крону каждые 5 минут, собирают различную статистику и выполняют служебные функции. Скрипты успешно отрабатывают, завершаются и исчезают из таблицы процессов, но после каждого запуска увеличивается показания счётчика dcachesize, который растёт линейно в течение некоторого времени и затем съедает всю память, выделенную контейнеру. Как это происходит, можно увидеть на графике.
При этом показания счётчиков UBC выглядят так:
----------------------------------------------------------------
CT 2003 | HELD Bar% Lim%| MAXH Bar% Lim%| BAR | LIM | FAIL
-------------+---------------+---------------+-----+-----+------
kmemsize|1.78G - - |1.78G - - | - | - | -
lockedpages| - - - | 32K - - | - | - | -
privvmpages| 236M - - | 416M - - | - | - | -
shmpages| 4K - - |2.57M - - | - | - | -
numproc| 38 - - | 123 - - | - | - | -
physpages|1.94G - 97%| 2G - 100%| - | 2G| -
vmguarpages| - - - | - - - | - | - | -
oomguarpages|73.1M - - |79.3M - - | - | - | -
numtcpsock| 8 - - | 17 - - | - | - | -
numflock| 8 - - | 16 - - | - | - | -
numpty| - - - | 3 - - | - | - | -
numsiginfo| - - - | 21 - - | - | - | -
tcpsndbuf| 136K - - | 708K - - | - | - | -
tcprcvbuf| 128K - - | 272K - - | - | - | -
othersockbuf| 133K - - | 372K - - | - | - | -
dgramrcvbuf| - - - |8.52K - - | - | - | -
numothersock| 117 - - | 158 - - | - | - | -
dcachesize|1.77G - - |1.77G - - | - | - | -
numfile| 836 - - |2.25K - - | - | - | -
numiptent| 39 - - | 39 - - | - | - | -
swappages|27.9M - 0.7%|29.2M - 0.7%| - | 4G| -
----------------------------------------------------------------
Хотя в процессах контейнера ничего необычного нет, всё довольно типично:
PID %CPU %MEM VSZ RSS STAT STARTED TIME COMMAND
18571 0.0 0.0 0 0 S 13:28:09 00:00:00 \_ kthreadd/2003
18572 0.0 0.0 0 0 S 13:28:09 00:00:00 \_ khelper/2003
18570 0.0 0.0 19232 1304 Ss 13:28:09 00:00:00 init
18722 0.0 0.0 10660 304 S<s 13:28:10 00:00:00 \_ udevd
19067 0.0 0.0 6160 500 Ss 13:28:11 00:00:00 \_ portreserve
19073 0.0 0.0 183544 1924 Sl 13:28:12 00:00:00 \_ rsyslogd
19084 0.0 0.0 197776 3488 S 13:28:12 00:00:19 \_ snmpd
19099 0.0 0.0 64076 600 Ss 13:28:12 00:00:00 \_ sshd
19106 0.0 0.0 22092 724 Ss 13:28:12 00:00:00 \_ xinetd
19141 0.0 0.0 108168 1244 S 13:28:12 00:00:00 \_ mysqld_safe
19218 0.0 0.2 969432 11636 Sl 13:28:12 00:01:18 | \_ mysqld
19240 0.0 0.0 64272 900 Ss 13:28:13 00:00:00 \_ saslauthd
19241 0.0 0.0 64272 644 S 13:28:13 00:00:00 | \_ saslauthd
19317 0.0 0.0 78680 2512 Ss 13:28:13 00:00:00 \_ master
19325 0.0 0.0 78932 3108 S 13:28:13 00:00:00 | \_ qmgr
294687 0.0 0.0 78760 3172 S 11:07:29 00:00:00 | \_ pickup
19327 0.0 0.0 52352 3032 S 13:28:13 00:00:06 \_ lighttpd
19329 0.0 0.2 235480 8172 Ss 13:28:13 00:00:00 | \_ php-cgi
19338 0.0 0.3 242604 12024 S 13:28:13 00:00:03 | | \_ php-cgi
19344 0.0 0.1 235480 6520 Ss 13:28:14 00:00:00 | \_ php-cgi
19345 0.0 0.2 243116 11080 S 13:28:14 00:00:06 | | \_ php-cgi
19346 0.0 0.2 235480 8172 Ss 13:28:14 00:00:00 | \_ php-cgi
19347 0.0 0.2 242592 11468 S 13:28:14 00:00:02 | | \_ php-cgi
19348 0.0 0.2 235480 8172 Ss 13:28:14 00:00:00 | \_ php-cgi
19349 0.0 0.4 248608 17828 S 13:28:14 00:00:08 | \_ php-cgi
58919 0.0 0.0 117212 1252 Ss 16:26:41 00:00:02 \_ crond
Конфигурационный файл контейнера также вполне стандартен:
PHYSPAGES="0:524288"
SWAPPAGES="0:1048576"
DISKSPACE="10485760:11534336"
DISKINODES="1000000:1100000"
QUOTATIME="0"
CPUUNITS="1000"
OSTEMPLATE="centos-6-x86_64"
ORIGIN_SAMPLE="vswap-2g"
ONBOOT="yes"
Версия ядра: 2.6.32-042stab061.2 (CentOS 6.3)
vzctl 4.0.
После перезагрузки контейнера dcachesize приходит в норму, затем опять линейно увеличивается по мере запуска скриптов, пока не съедает всю память.
Из подозрительного, в логах были сообщения:
Oct 9 01:00:02 tools2 kernel: [4025069.891406] VZDQ: Tried to clean orphans on qmblk with 1 state
Oct 9 01:00:02 tools2 kernel: [4025069.891411] BUG: Quota files for 2003 are broken: no quota engine running
Но они исчезли после пересоздания квоты и (или) перезагрузки хост-ноды.
И один раз во время перезагрузки контейнера, получил такие сообщения в лог:
Oct 9 10:35:34 tools2 kernel: [4059601.590679] CT: 2003: stopped
Oct 9 10:35:34 tools2 kernel: [4059601.598205] UB: 2003 has 31 swap entries to unuse.
Oct 9 10:35:34 tools2 kernel: [4059601.739865] Ub 2003 helds 4360 in tcpsndbuf on put
Oct 9 10:35:34 tools2 kernel: [4059601.739873] UB: leaked beancounter 2003 (ffff88012df70040)
Oct 9 10:35:54 tools2 kernel: [4059621.003883] CT: 2003: started
Я пробовал перезагружать хост-ноду во время обновления ядра, это никак не отразилось на поведении счётчика.
С подобной проблемой столкнулся впервые, хотя пользуюсь OpenVZ уже много лет. В связи с этим вопрос, чем может быть вызвано такие показания счётчиков - виноваты скрипты или следует подозревать утечки в ядре? Если скрипты, подскажите, чем именно такое поведение может быть вызвано?
|
|
|
|
OpenVZ Forum
Members
Search
Help
Register
Login
Home
