OpenVZ Forum


Home » International » Russian » Странный рост показаний счётчика dcachesize
Странный рост показаний счётчика dcachesize [message #48265] Wed, 10 October 2012 11:24 Go to next 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 уже много лет. В связи с этим вопрос, чем может быть вызвано такие показания счётчиков - виноваты скрипты или следует подозревать утечки в ядре? Если скрипты, подскажите, чем именно такое поведение может быть вызвано?
Re: Странный рост показаний счётчика dcachesize [message #48269 is a reply to message #48265] Wed, 10 October 2012 14:06 Go to previous messageGo to next message
kopytov is currently offline  kopytov
Messages: 17
Registered: July 2007
Location: Cyprus, Limassol
Junior Member
From: *netrun.cytanet.com.cy
После публикации темы я догадался сравнить с графиком использования памяти у хост-ноды за тот же самый период:
index.php?t=getfile&id=1050&private=0

Как видно из графика, использование памяти на ноде практически постоянное, двухгигабайтный всплеск был бы заметен. Это даёт основания полагать, что ядро "накручивает" счётчик dcachesize, но реального расхода памяти при этом не происходит.

Открыл тикет в багзилле: Possible dcachesize counter leak on SolusVM cron jobs executing.
Re: Странный рост показаний счётчика dcachesize [message #48481 is a reply to message #48265] Thu, 18 October 2012 11:01 Go to previous messageGo to next message
kir is currently offline  kir
Messages: 1645
Registered: August 2005
Location: Moscow, Russia
Senior Member

From: *sw.ru
1 покажите
cat /proc/bc/$VEID/dcacheinfo

2 сколько у вас в контейнере файлов?


Kir Kolyshkin
http://static.openvz.org/userbars/openvz-developer.png
Re: Странный рост показаний счётчика dcachesize [message #48488 is a reply to message #48481] Thu, 18 October 2012 11:55 Go to previous messageGo to next message
kopytov is currently offline  kopytov
Messages: 17
Registered: July 2007
Location: Cyprus, Limassol
Junior Member
From: *netrun.cytanet.com.cy
Вывод /proc/bc/2003/dcacheinfo на хост-ноде:
       usage device     fstype  mount   dentry
  1026030642 dm-2       ext4    /vz     /private/2003
      137561 devtmpfs   devtmpfs        /vz/root/2003/dev       /
         911 sysfs      sysfs   /vz/root/2003/sys       /
         911 mqueue     mqueue  none    /
       49194 proc       proc    /vz/root/2003/proc      /
         911 tmpfs      tmpfs   none    /
        2733 devpts     devpts  /vz/root/2003/dev/pts   /
         911 tmpfs      tmpfs   /vz/root/2003/dev/shm   /
        2733 binfmt_misc        binfmt_misc     /vz/root/2003/proc/sys/fs/binfmt_misc   /


Вывод df -i внутри контейнера:
Файловая система      Iнодов   IИспол  IСвоб IИсп% смонтирована на
/dev/simfs           1000000   33301  966699    4% /
none                  262144     151  261993    1% /dev
none                  262144       1  262143    1% /dev/shm

Re: Странный рост показаний счётчика dcachesize [message #48517 is a reply to message #48488] Fri, 19 October 2012 13:38 Go to previous messageGo to next message
kir is currently offline  kir
Messages: 1645
Registered: August 2005
Location: Moscow, Russia
Senior Member

From: *sw.ru
Я наконец разобрался в этом вопросе и смогу популярно объяснить, что это и зачем и почему.

dcachesize контролирует размер dentry и inode кешей.

Про dentry кеш. Когда кто-то открывает какой-нибудь файл, скажем, /var/log/httpd/access_log, в dentry кеше появляются объекты для /, var, log, httpd и для access_log, то есть пять штук (впрочем, / там уже скорее всего есть). Соответственно, когда в следующий раз кто-то будет смотреть в /var/log/httpd/access/log (или просто в /var) -- ядро будет использовать этот кеш. Второе открытие (или stat, например) того же самого файла не будет приводить к увеличению кеша -- там все эти объекты уже есть.

К примеру, можно «вырастить» размер dcache командой ls -lR /, которая по-stat()-ает все имеющиеся файлы. Если запустить ls -lR / сразу ещё раз, dcache уже не подрастёт. Для обычного контейнера значение будет несколько десятков мегабайт.

Отсюда у юношей, обдумывающих житьё, возникает справедливый и каверзный вопрос -- а как тогда удаётся подрастить dcache до ужасающих значений в 12 гигабайта, если в системе нет такого количества файлов? Ага! Бага!! БАГА!!!

Нет, не бага. Дело в том, что от файла, которого НЕТ, dentry тоже кешируется (чтобы в следующий раз быстрее ответить на вопрос, есть ли такой файл). Теперь, если создавать и удалять много временных файлов (впрочем, достаточно просто генерировать рандомное имя файла и делать на него stat() или access() или open()), то можно вырастить dcache до упора.

«Упором» в данном случае может являться
-- barrier/limit бинкаунтера dcachesize в конкретном контейнере
-- barrier/limit бинкаунтера kmemsize (в него включается dcachesize)
-- limit бинкаунтера physpages (на 042stab ядре в него включается kmemsize)
-- объём свободной памяти в системе

Обычно на vswap-enabled конфигах упором является physpages или объём свободной памяти. В вашем случае, судя по всему, памяти в системе много, и кто-то делает что-то вроде создания/удаления временных файлов, вот кеш и вырастает до максимально возможного размера. Это абсолютно нормальное, правильное и разумное поведение системы.

Дальше, если памяти хватать не будет, кеш уменьшится в объёме, ядро само подропает наиболее редко используемые объекты кеша.

Это такая теория. Практика чуть позже.


Kir Kolyshkin
http://static.openvz.org/userbars/openvz-developer.png
Re: Странный рост показаний счётчика dcachesize [message #48548 is a reply to message #48265] Mon, 22 October 2012 05:54 Go to previous messageGo to next message
koct9i is currently offline  koct9i
Messages: 51
Registered: February 2008
Member
From: *sw.ru
dcache считается в ресурсы dcachesize и kmemsize, а kmemsize поделённый на 4096 считается в physpages.
Так что поставьте лимит на dcachesize или kmemsize, скажем в 1Gb.
В том ядре был баг что лимит на physpages не очень хорошо лимитирует dcache и ядро может постреливать OOM-килами время от времени.
Re: Странный рост показаний счётчика dcachesize [message #48553 is a reply to message #48265] Mon, 22 October 2012 11:16 Go to previous messageGo to next message
kopytov is currently offline  kopytov
Messages: 17
Registered: July 2007
Location: Cyprus, Limassol
Junior Member
From: *netrun.cytanet.com.cy
Спасибо за подробное разъяснение. Всё происходит так как вы говорите. Я попробовал проверить в тестовом контейнере и вот такой скрипт увеличил dcachesize до гигабайтов за считанные минуты:
#!/usr/bin/perl
use strict;
use warnings;
use File::Temp ();

while (1) {
    my $tmp_fh    = File::Temp->new();
    my $tmp_fname = $tmp_fh->filename(); 
    my @tmp_stat  = stat $tmp_fname;
    unlink $tmp_fname;
}


При этом, когда достигается предел, память больше не расходуется и ничего страшного не происходит - даже ООМ-киллер никого не трогает.

Единственное что мне осталось непонятно, откуда такое расхождение в показаниях занятости памяти в контейнере и на хост-ноде. Если посмотреть на графики, которые я опубликовал вначале, то на них видно, что за эти 12 часов в контейнере потребление памяти выросло примерно на 1,8-1,9 Гбайт, но в самой системе - на 450-500 Мбайт. Разница почти в четыре раза, что выглядит довольно странным.

koct9i wrote on Mon, 22 October 2012 08:54
dcache считается в ресурсы dcachesize и kmemsize, а kmemsize поделённый на 4096 считается в physpages.
Так что поставьте лимит на dcachesize или kmemsize, скажем в 1Gb.
В том ядре был баг что лимит на physpages не очень хорошо лимитирует dcache и ядро может постреливать OOM-килами время от времени.

Спасибо за совет, так и сделаю.
Re: Странный рост показаний счётчика dcachesize [message #48561 is a reply to message #48553] Mon, 22 October 2012 19:14 Go to previous message
koct9i is currently offline  koct9i
Messages: 51
Registered: February 2008
Member
From: *broadband.corbina.ru
kopytov wrote on Mon, 22 October 2012 15:16
Единственное что мне осталось непонятно, откуда такое расхождение в показаниях занятости памяти в контейнере и на хост-ноде. Если посмотреть на графики, которые я опубликовал вначале, то на них видно, что за эти 12 часов в контейнере потребление памяти выросло примерно на 1,8-1,9 Гбайт, но в самой системе - на 450-500 Мбайт. Разница почти в четыре раза, что выглядит довольно странным.


Просто что-то ещё параллельно освобождалось, на хосте или в другом контейнере. Ядро держит очень небольшой резерв свободной памяти, остальное используется для всевозможных кэшей которые быстро освобождаются по первому требованию.
Previous Topic: После сбоя питания не поднимается контейнер KVM
Next Topic: Проблемы с пробросом сетевых карт intel pro 100
Goto Forum:
  


Current Time: Fri Aug 23 21:54:58 GMT 2019