OpenVZ Forum


Home » International » Russian » Странный рост показаний счётчика dcachesize
Странный рост показаний счётчика dcachesize [message #48265] Wed, 10 October 2012 11:24 Go to previous message
kopytov is currently offline  kopytov
Messages: 17
Registered: July 2007
Location: Cyprus, Limassol
Junior Member
From: *netrun.cytanet.com.cy
Я столкнулся с очень странной проблемой роста параметра dcachesize в одном из контейнеров. Контейнер создан на базе официального образа centos-6-x86_64, поверх которого установлена контрольная панель для управления хост-нодами. В состав контрольной панели входят скрипты, которые запускаются по крону каждые 5 минут, собирают различную статистику и выполняют служебные функции. Скрипты успешно отрабатывают, завершаются и исчезают из таблицы процессов, но после каждого запуска увеличивается показания счётчика dcachesize, который растёт линейно в течение некоторого времени и затем съедает всю память, выделенную контейнеру. Как это происходит, можно увидеть на графике.
index.php?t=getfile&id=1049&private=0

При этом показания счётчиков 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 уже много лет. В связи с этим вопрос, чем может быть вызвано такие показания счётчиков - виноваты скрипты или следует подозревать утечки в ядре? Если скрипты, подскажите, чем именно такое поведение может быть вызвано?
 
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: После сбоя питания не поднимается контейнер KVM
Next Topic: Проблемы с пробросом сетевых карт intel pro 100
Goto Forum:
  


Current Time: Mon Sep 16 06:19:31 GMT 2019