Home » International » Russian » swap/mem
| swap/mem [message #39283] |
Sat, 03 April 2010 13:05  |
bindto
Messages: 6
Registered: April 2010
|
Junior Member |
|
|
имеется контейнер, который в некоторый момент напоролся на лимит.
resource held maxheld barrier limit failcnt
kmemsize 9138939 20530451 40480000 2147483647 6146
privvmpages 38883 79332 524288 549888 0
physpages 9890 36648 2147483647 2147483647 0
vmguarpages 0 0 262144 2147483647 0
oomguarpages 9890 36649 2147483647 2147483647 0
kmemsize был увеличен. однако вопрос тут, почему контейнер не ушел в свап? при этом процесс, жрущий память (httpd), тоже не кильнул.
в результате, даже на vzctl stop завис.
Linux 2.6.18-164.11.1.el5.028stab068.3ent RHEL5
[Updated on: Sat, 03 April 2010 13:09] Report message to a moderator |
|
|
|
| Re: swap/mem [message #39293 is a reply to message #39283] |
Sat, 03 April 2010 18:40  |
RXL_
Messages: 147
Registered: July 2009
Location: Moscow/Russia
|
Senior Member |
|
|
| Quote: |
--kmemsize bytes[:bytes]
Maximum amount of kernel memory used. This parameter is related to --numproc. Each process consumes certain amount of kernel memory - 16 KB at leas, 30-50 KB typically. Very large processes may consume a bit more. It is important to have a certain safety gap between the barrier and the limit of this parameter: equal barrier and limit may lead to the situation where the kernel will need to kill container's applications to keep the kmemsize usage under the limit.
|
Тут ни слова о свопировании.
Кстати, почему не устанавливаете лимит, а только барьер?
http://wiki.openvz.org/UBC_secondary_parameters#kmemsize
... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
[Updated on: Sat, 03 April 2010 18:56] Report message to a moderator |
|
|
|
| Re: swap/mem [message #39294 is a reply to message #39293] |
Sat, 03 April 2010 19:40 |
bindto
Messages: 6
Registered: April 2010
|
Junior Member |
|
|
да, kmemsize к свапу не имеет никакого отношения, но я специально привел другие параметры. вопрос тот же, почему контейнер не ушел в свап?
по поводу kmemsize limit, возможно я не понял документацию,
но посчитал что
KMEMSIZE="40480000:2147483647"
второе значение это макс возможный лимит для х86, и если его указать - это означает вся доступная память, что меня вполне устраивает, поскольку идея не в ферме, а изоляции сервиса.
я здесь сделал что-то не так?
и здесь наверно связанный вопрос, почему контейнер не пошел за барьер с этим лимитом?
[Updated on: Sat, 03 April 2010 19:42] Report message to a moderator |
|
|
|
| Re: swap/mem [message #39299 is a reply to message #39294] |
Sat, 03 April 2010 20:47 |
RXL_
Messages: 147
Registered: July 2009
Location: Moscow/Russia
|
Senior Member |
|
|
Для kmemsize надо указать лимит. Это на вопрос, почему процесс не был убит.
Свопироваться структуры ядра не должны.
Контейнер не свопировался потому, что в системе было достаточно памяти.
... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
[Updated on: Sat, 03 April 2010 20:49] Report message to a moderator |
|
|
|
|
|
| Re: swap/mem [message #39305 is a reply to message #39303] |
Sun, 04 April 2010 07:41 |
RXL_
Messages: 147
Registered: July 2009
Location: Moscow/Russia
|
Senior Member |
|
|
Почему же не поддерживает? Страницы контейнера могут свопироваться. Вопрос в лимите - сколько задано в privvmpages.
Скажем, тут privvmpages составляет 2 ГБ - значит можно условно считать, что размер RAM + SWAP = 2 ГБ.
Несвопируемая часть - lockedpages. Если я понял из доки, kmemsize, буфера сокетов и прочие ядерные структуры в зачет не идут: privvmpages относится к user space. Также кеш файлов в зачет не идет - он общий для всей системы.
... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
|
|
|
|
| Re: swap/mem [message #39309 is a reply to message #39299] |
Sun, 04 April 2010 08:53 |
bindto
Messages: 6
Registered: April 2010
|
Junior Member |
|
|
| RXL_ wrote on Sat, 03 April 2010 15:47 | Для kmemsize надо указать лимит. Это на вопрос, почему процесс не был убит.
Свопироваться структуры ядра не должны.
Контейнер не свопировался потому, что в системе было достаточно памяти.
|
проясните этот момент - "kmemsize надо указать лимит." я считал, что задал его максимально возможным значением, это не так?
или максимально возможный параметр значит "нет значения"?
тогда почему в других параметрах, тот же oomguarpages , это
работает?
по поводу двух других ответов, свап юзался, если я правильно
понял этот параметр
oomguarpages 9890 36649 2147483647 2147483647 0
и вот здесь возникает другой интересный вопрос, почему
apache+php уляглись в kernel. поскольку без openvz это все
использует свап.
|
|
|
|
| Re: swap/mem [message #39310 is a reply to message #39309] |
Sun, 04 April 2010 14:02 |
RXL_
Messages: 147
Registered: July 2009
Location: Moscow/Russia
|
Senior Member |
|
|
Надо следовать документации: в одних параметрах действителен только барьер, а других - и барьер, и лимит. Когда лимит не используется, он должен быть установлен в максимальное значение для целого на данной платформе.
Если перевести терминологию OpenVZ на привычные лимиты Unix, то:
- барьер - мягкий лимит (soft limit);
- лимит - жесткий лимит (hard limit).
Не поручусь за точность объяснения, но логика примерно такая: контейнер приблизился к барьеру и приложение в нем запрашивает блок памяти. Если уже израсходованная память + новый блок укладываются в диапазон "soft:hard", то память выделяется, если происходит превышение "hard", то приложение получает ошибку выделения "out of memory". Если на момент запроса приложением блока памяти контейнер уже вошел в диапазон "soft:hard", то приложение получит "out of memory". Это такой защитный диапазон.
По этому, если установлен барьер kmempages, но не установлен лимит, то приложение может запросить очень большой блок памяти - много больше, чем указано в барьере. По этому лимит надо тоже ставить (если в доке не сказано обратное).
Насчет свопирования.
Единственный способ в приложении управлять свопированием - использовать блокирование страниц памяти (это лимитируется параметром lockedpages). Во всех остальных случаях используются алгоритмы ядра, определяющие, какая страница пойдет в своп следующей.
Еще раз: виртуальная память и физическая память - разные вещи. Физической памятью может оперировать только ядро. Все остальные системы (и user space особенно) оперируют вирутальной памятью.
В общем, думаю, что вам еще раз и очень внимательно надо почитать документацию, отбросив собственные представления о процессе управления памятью.
... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
[Updated on: Sun, 04 April 2010 14:22] Report message to a moderator |
|
|
|
|
|
|
|
| Re: swap/mem [message #39328 is a reply to message #39326] |
Mon, 05 April 2010 12:54 |
|
|
Этот параметр ничего особенного не означает -- если его барьер выставить, то free и прочие будут показывать, что как будто бы вот столько свопа есть в VE. Если не выставить, то free и прочие будут показывать, сколько свопа есть на ноде. Никакого отношения к тому, как на самом деле будет использоваться своп, это не имеет. Но вот значение held для swappages представляет некоторый интерес -- там вы можете увидеть, сколько страничек из этого контейнера упали в своп.
Не знаю, зачем я тут это пишу, потому что про это написано в документации по ссылке, которую вы дали.
Kir Kolyshkin
|
|
|
|
|
|
| Re: swap/mem [message #39332 is a reply to message #39310] |
Mon, 05 April 2010 18:56 |
bindto
Messages: 6
Registered: April 2010
|
Junior Member |
|
|
| RXL_ wrote on Sun, 04 April 2010 10:02 | Надо следовать документации:
в одних параметрах действителен только барьер, а других - и барьер, и лимит. Когда лимит не используется, он должен быть установлен в максимальное значение для целого на данной платформе.
|
не могли бы вы показать, где написано
"Когда лимит не используется, он должен быть установлен в максимальное значение для целого на данной платформе."
http://wiki.openvz.org/UBC_parameters
вроде вот здесь полное описание и только одно упоминание о максимальном значении.
| RXL_ wrote on Sun, 04 April 2010 10:02 |
По этому, если установлен барьер kmempages, но не установлен лимит, то приложение может запросить очень большой блок памяти - много больше, чем указано в барьере. По этому лимит надо тоже ставить (если в доке не сказано обратное).
|
есть апп, которые страдают попытками прихватить всю доступную память, но все ж перед этим проверяют ее наличие.
поэтому не вижу здесь принципиального отличия, в любом случае, установлен лимит или нет, при запросе больше доступного,
реакция должна быть та же - отказ.
просмотрел конфиги, которые генерирует paralles, он весьма бодро юзает вместо лимитов макс значение.
вопрос перешел в разряд теретических, я установил реальный лимит.
| RXL_ wrote on Sun, 04 April 2010 10:02 |
Еще раз: виртуальная память и физическая память - разные вещи. Физической памятью может оперировать только ядро. Все остальные системы (и user space особенно) оперируют вирутальной памятью.
В общем, думаю, что вам еще раз и очень внимательно надо почитать документацию, отбросив собственные представления о процессе управления памятью.
|
вы не совсем точно определили проблему, вопрос не в моем знании работы с памятью, хотя я считаю его впольне правильными и достаточными, а в том, что не так в кофигурации, которая заставила контейнер отказаться свапиться.
или мне стоит начать думать, что http и php исконные жители кернел спейс? 
|
|
|
|
| Re: swap/mem [message #39333 is a reply to message #39328] |
Mon, 05 April 2010 19:19 |
bindto
Messages: 6
Registered: April 2010
|
Junior Member |
|
|
| kir wrote on Mon, 05 April 2010 08:54 | Этот параметр ничего особенного не означает -- если его барьер выставить, то free и прочие будут показывать, что как будто бы вот столько свопа есть в VE. Если не выставить, то free и прочие будут показывать, сколько свопа есть на ноде. Никакого отношения к тому, как на самом деле будет использоваться своп, это не имеет. Но вот значение held для swappages представляет некоторый интерес -- там вы можете увидеть, сколько страничек из этого контейнера упали в своп.
Не знаю, зачем я тут это пишу, потому что про это написано в документации по ссылке, которую вы дали.
|
надо сюда же добваить, что параметр доступен в версии vzctl >=3.0.24 и не виден в /proc/user_beancounters, а только в /proc/bc/resources.
и вопрос тут
"Если не выставить, то free и прочие будут показывать, сколько свопа есть на ноде."
доступного свапа или используемого на текущий момент?
free
Swap: 0 0 0
получается свапа нет?
swappages 0 1 2147483647 147483647 0
хотя одна страница таки упала.
[Updated on: Mon, 05 April 2010 19:28] Report message to a moderator |
|
|
|
| Re: swap/mem [message #39550 is a reply to message #39333] |
Sun, 09 May 2010 12:49 |
andreyb
Messages: 25
Registered: February 2008
|
Junior Member |
|
|
| Quote: | не виден в /proc/user_beancounters, а только в /proc/bc/resources
|
А не является ли это небольшим багом?
| Quote: | free
Swap: 0 0 0
получается свапа нет?
|
В документации:
If the limit is set to MAX_ULONG (which is the in-kernel default for this parameter), all the swap space values parameters (total, used, free) are reported as 0.
[Updated on: Sun, 09 May 2010 12:51] Report message to a moderator |
|
|
|
Goto Forum:
Current Time: Sat Jul 27 06:39:22 GMT 2024
Total time taken to generate the page: 0.03226 seconds
|
OpenVZ Forum
Members
Search
Help
Register
Login
Home
