домовой (kyzia) wrote in ru_openvz,
домовой
kyzia
ru_openvz

Category:

Управление оперативной памятью в openvz контейнерах. Vswap.

Открыли для себя новые ядра от Openvz через alien в debian'е :)

Вопросы:

1. При использовании Vswap все параметры кроме physpages и swappages можно выставлять в unlimited (то есть явно не указывать)? И вообще забить на них (нужно ли комбинировать Vswap и UBC счетчики)?

2. Параметр tcpsndbuf выставленный в unlimit может повлият на работоспособность других контейнеров в системе?

3. Если использовать physpages и swappages то процесс который выжирает памяти больше чем есть в свопе и физической памяти - убивается через механизм oomguarpages, хотя раньше можно было через privvmpages просто запретить ему брать больше памяти. Т.е. я не хочу чтобы процесс внутри машины убивался при попытке выжрать больше - хочу чтобы ему просто били по рукам. Это реально, и нормально ли такое мое желание?

4. Есть ли вообще подводные камни при использовании Vswap или уже давно нужно было переходить?

Буду благодарен за любые пруфы и любую полезную инфу об использовании Vswap в продакшене.

Как я понимал это раньше - для управления оперативной памятью, в ovz раньше служили три параметра (тут много букв):

vmguarpages - оперативная гарантированная память доступная для контейнера, если контейнер работает в пределах этого гарантированного куска (barrier и limit параметры) оперативная память для него всегда есть. Если контейнер выходит по потреблению памяти за параметры barrier и limit, но при этом используемое количество памяти меньше чем указано в barrier у privvmpages то память может быть выделена или нет - в зависимости от доступной памяти в системе. Если с-нно использование памяти превышает limit у privvmpages то новое выделение памяти всегда оканчивается неудачей.

oomguarpages - гарантированное количество памяти при out of memory ситуациях. Если текущий размер суммы параметров: памяти, свопа, буферов и kmemsize у контейнера меньше чем barrier у этого параметра - то процессы в контейнере гарантированно не будут убиты. Если суммарное количество используемой контейнером памяти превышает barrier то первыми процессы будут убиваться у тех контейнеров где это превышение выше. Превышение счетчика limit - значит был убит какой то процесс по out of memory для этого контейнера. Если мы не хотим чтобы процессы в этом контейнере убивались - выставляем barrier в два раза большим чем limit у privvmpages.

privvmpages - количество оперативной памяти которое "видно" в контейнере. Этот параметр как правило больше чем vmguarpages. При превышении параметра barrier процессам можно форкаться но нельзя создавать новые, при превышении параметра limit новые процессы не могут создаваться вообще.

Таким образом раньше было так:
-Например мы знаем что контейнеру гарантируется 2 гигабайта оперативки
-На хосте доступно 8 гигабайт оперативной памяти,
-Всего работает 2 контейнера, возможны всплески по использованию до 3 гигабайт):

-Выставляем vmguarpages в 2 гигабайта.
-Выставляем privvmpages в 3 гигабайта barrier и 4 гигабайта limit (к примеру),
-Выставляем oomguarpages barrier в 3 гигабайта для каждого контейнера.

Таким образом:
-2 гига гарантируется каждому контейнеру.
-При одновременном превышении потребляемой памяти лимита до 4 гигабайт на каждый хост (при этом новые процессы не смогут форкаться уже при 3 гигабайтах на контейнер) если хост система будет в состоянии нехватки памяти - убиваться процессы по out of memory будут у того контейнера те кто дальше прошел за barrier oomguarpages который выставлен на 3 гига.

Т.о. оперативная память в контейнерах будет потребляться равномерно, убиваться процессы будт вряд ли - так как в хост системе еще остается около двух гигов оперативной памяти (плюс своп, минус сами процессы хост системы) и она не будет переходить в состояние когда памяти не хватает.

В общем схему, наверно, можно предположить такую примерно: vmguarpages = x, privvmpages barrier = x+200mb, privvmpages limit = x+400mb >= oomguarpages.
Subscribe

  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

  • 6 comments