Comments 30
Видимо, чтобы был. Я где-то читал, что бывают проги, которые без свопа не хотят работать, может они решили так подстраховаться.
Ну да, только это было, наверное, во времена Windows 98.
Нууу...
Не так давно столкнулся с вылетами игрульки The Division 2 от Ubisoft на Win10 с отключённым swap. Вылетала стабильно через 15-30 минут игры, ничего внятного не писала, RAM даже на половину не была заполнена.
Создание свапа на гигабайтик решило проблему полностью.
Это связано с исчерпанием виртуальной памяти, а не с отсутствием свопа. Посмотрите, ради интереса, значение Commit Size — общее количество выделенной виртуальной памяти, и увидитесь, насколько оно велико по сравнению с реально используемой памятью.
То есть ситуация, когда при отсутствии свопа игра использует только 5-6 гигов памяти, а выделило 10-11 — абсолютно нормальная. Аналогичная фигня была, когда я гонял нейросетки. Судя по всему, это связано с маппингом памяти видеокарты в общее виртуальное пространство. То есть к объёму реально используемой памяти надо добавлять ещё и объём видеопамяти.
А всё дело в том, что в винде нет оверкоммита — ситуации, когда система позволяет выделить больше памяти, чем ей доступно, из расчёта на то, что большая часть страниц использоваться не будет.
Проблема решается как включением свопа, так и увеличением количества оперативной памяти.
А всё дело в том, что в винде нет оверкоммита
Есть там оверкоммит, по крайне мере в Win 10. Запустите Process Explorer, включите в колонках "Virtual Size" (запрошенная но не использованная память) и увидите что процессы запрашивают намного больше чем в сумме дают своп + оперативка. У меня 32G памяти, свопа нет совсем, и вот такое:
void* ram = malloc((size_t)256 * 1024 * 1024 * 1024);отлично работает (VS, x64), ProcessExplorer честно показывает выделенные 256G. Реально же память начнёт использоваться только по мере обращения.
Кстати, в этой же конфигурации никогда не было проблем из-за отсутствия свопа, кроме пары ситуаций когда кто-то реально сожрал всю память.
void ram = malloc((size_t)256 1024 1024 1024);
А у меня почему-то не работает (ram == NULL). И во всех документациях написано, что malloc в Windows приводит именно к выделению (commit) всей запрошенной памяти. Может, этот режим включается как-то отдельно?
Virtual Size
А вот здесь вы путаете состояния reserved и commiitted (link). Зарезервировать вы можете сколько угодно адресного пространства (точнее, пока не исчерпается таблица страниц), вот только чтобы эту память можно было использовать, её все равно нужно закоммитить.
Скорее всего, в вашем случае память сначала резервируется менеджером памяти, а дальше при выделении происходит ошибка. Из-за этого вы видете огромный Virtual Size, которые вообще ничего не значит.
А у меня почему-то не работает (ram == NULL).
Интересный расклад… Да, каюсь, не проверял — у меня тоже ram == NULL, я смотрел только размер процесса — и он (Virtual size) соответствует запросу, несмотря на то что malloc() возвращает NULL. С другой стороны:
void *ram = VirtualAlloc(NULL, (size_t)256 * 1024 * 1024 * 1024, MEM_RESERVE, PAGE_READWRITE);точно вернёт не NULL, и это попадёт в Virtual size. Правда, использовать его без явного commit тоже не получится.
А вот здесь вы путаете состояния reserved и commiitted
Virtual size это почти полный эквивалент линуксового VSZ, это именно reserved (в обоих системах), и размер reserved space может значительно превышать имеющуюся физическую память. Committed, в свою очередь, это либо использованный (= к нему обратились) участок памяти (RSS в Linux), либо явно указали что хотят его "живым" (Private bytes в Windows, если же оно реально использовано — то Working set).
Overcommit же обозначает только что что можно получить у системы адресное пространство по размеру больше чем размер памяти и свопа, но не даёт гарантий что его можно использовать. Таким образом, overcommit в Linux всё равно не даст вам получить и использовать больше чем у вас RAM + swap, другое дело что это более прозрачно для приложений.
Virtual size это почти полный эквивалент линуксового VSZ, это именно reserved (в обоих системах), и размер reserved space может значительно превышать имеющуюся физическую память.
Это просто резервирование адресов внутри процесса, к реальному выделению памяти это не имеет никакого отношения.
Committed, в свою очередь, это либо использованный (= к нему обратились) участок памяти (RSS в Linux), либо явно указали что хотят его "живым" (Private bytes в Windows, если же оно реально использовано — то Working set).
Уже ближе. Если память закоммитить, но не использовать, то страницы будут указывать на страницу, заполненную нулями, а реальный маппинг на физическую память или своп произойдёт только при первой записи в страницу (copy-on-write). И именно в этом случае произойдёт увеличение значения RSS или Private Bytes.
Таким образом, overcommit в Linux всё равно не даст вам получить и использовать больше чем у вас RAM + swap, другое дело что это более прозрачно для приложений.
Как раз нет, overcommit и заключается в том, что приложения могут суммарно закоммитить больше памяти, чем операционная система может предоставить, исходя из предположения, что к части памяти обращений не будет вообще.
Поэтому в Linux возможна ситуация, когда приложение крашится не на malloc, а в процессе заполнения выделенной памяти.
В Windows же, наоборот, такая ситуация невозможна, т.к. операционная система исходит из предположения, что приложению может потребоваться вся закоммиченная память, и держит эту память в резерве, даже если она никогда не понадобится.
Это просто резервирование адресов внутри процесса, к реальному выделению памяти это не имеет никакого отношения.
malloc() в линуксе (точнее, brk(), а также mmap()) тоже только резервирует, реальное выделение идёт после обращения. Собственно, в этом и разница — в линуксе это прозрачно, в вынь — нужно явно выделять.
Поэтому в Linux возможна ситуация, когда приложение крашится не на malloc, а в процессе заполнения выделенной памяти.
И чем это принципиально отличается от того что я сказал?
Таким образом, overcommit в Linux всё равно не даст вам получить и использовать больше чем у вас RAM + swap, другое дело что это более прозрачно для приложений.
Тот факт что крэш будет не на malloc() мало что меняет для большинства приложений, потому что большинство, всё же, либо сразу использует (пытается) запрошенную память, либо использует calloc(), если же оно осознаёт что памяти может быть меньше чем хочется, то вполне в состоянии явно управлять выделением (committing).
Overcommit в том виде как реализован в Linux реально хорош только когда у вас куча KVM или чего-то вроде (причём вы точно знаете что они никогда не вылезут за реальную память одновременно), или совсем уж специальные задачи где нужен большой непрерывный кусок памяти с редкими использованными блоками в нём.
потому что большинство, всё же, либо сразу использует (пытается) запрошенную память, либо использует calloc(), если же оно осознаёт что памяти может быть меньше чем хочется, то вполне в состоянии явно управлять выделением (committing).
Ну вот же пример: игры. Закоммичено 10-11 гигов, реально используется 4-5 гигов, а ещё для порядка 6 гигов система тупо резервизует место в оперативке + своп. В итоге на компе с 16 гигами оперативки приходится включать своп, чтобы поиграть, не закрывая при этом все остальные приложения.
Насколько я понимаю из беглого гуглежа, это связано с внутренней кухней D3D и отображением видеопамяти в системную память. То есть если видеокарта имеет много памяти, и игра её всю использует, то придётся увеличить сумму (оперативка + своп) на размер видеопамяти.
Смысл в том, что при высокой утилизации ram, часть неиспользуемых данных может быть перенесена в swap, освободив место под буферы файловой системы, что хорошо скажется на производительности. Кроме того, если вдруг используется zswap (а у нас такие ноды есть), то это must have.
Нет. Система пишет в своп большими кусками — write amplification получается достаточно низкий, поэтому ресурса SSD хватает надолго. Не вижу смысла его жалеть, потому что комфорт от использования SSD стоит дороже затрат.
У меня вот SSD с 72000 часов работы, своп на нём. Совсем недавно ресурс с 98% до 97% снизился. Скорее, я его заменю по причине морального устаревания.
А не подскажете, раз уж зашла тема, как оно на Windows Server? У меня 2008r2 на ssd стоит, причем перенесенный с обычного жесткого. Долго обычный бытовой диск проживёт?
Просто посмотрите данные SMART диска на предмет media wearout.
От вендора зависит, на самом деле. Там ещё всякие значения с инфой о частоте ошибок, количестве ячеек при смерти и т.д.
У меня один из самых первых SSD посыпался уже через 1.5 года, видимо по причине сырой прошивки в контроллере, которая не умела равномерно писать на весь диск и давала write amplification в пару сотен. Довольно быстро начала деградировать скорость записи, а при остатке ресурса 70% начали портиться данные — искажался 1 байт на пару мегабайт данных, а это гораздо хуже, чем просто смерть диска. Данные SMART показали, что была ячейка, которая пережила уже больше 100 тысяч перезаписей.
Добрый день. Никак мы это не делаем (NVME), о чем в статье и написано — мы используем QCOW2 в файловой системе EXT4/XFS.
Сколько vm на ноде? Столько, чтобы не начался steal между VM и влезали на RAM и хранилище. По нашему опыту и дизайну даже при полных занятых 256 GB больше 80% занятого CPU мы не видели. На практике всегда можно переместить "энергичную" VM на другой узел.
Второй вопрос — почему вы не делаете снапшоты средствами QEMU (external snapshot)?
LVM VG повредилась непонятно почему, поэтому тема и не раскрыта. Предполагаю, что во время того как под очень высоким LA сервер находился, что-то у LVM отработало нестандартно (в логах было пусто на эту тему).
Второй вопрос — почему вы не делаете снапшоты средствами QEMU (external snapshot)?
Это системный бэкап «судного дня», пользователи же могут делать бэкапы с помощью средств Apache CloudStack, который использует возможности Qemu, но может фризить виртуалки на несколько секунд.
Ибо вот эта штука все еще работает и не только в RH: bugzilla.redhat.com/show_bug.cgi?id=920020 (в общем, без фриза под большой нагрузкой, при создании снимка, тома QCOW2 могут повреждаться). Я это видел раза два. Если мы будем делать снимки средствами Libvirt, нам придется фризить VM в произвольное время, чтобы сделать снимок без угрозы состоянию тома QCOW2.
Более того, без настроенного внутри VM qemu-agent все равно разницы никакой нет, а qemu-agent стоит не во всех VM.
Ну, и в целом, мы стремимся к надежности. Условный «системный» уровень LVM и DM мы считаем куда более надежным, чем «прикладной» уровень QEMU/LibVirt.
Но я говорил о external snapshot, он не использует возможности QCOW, все операции со снапшотом делаются QEMU, можно снапшотить даже raw диски.
Почему не используете понятно.)
UPD: все же без обширного тестирования я бы на это не пошел. К примеру, у меня 500 VM, делаю я бэкапы 1 раз в сутки — 182500 бэкапов в год.
Насколько этот код такой же зрелый как и для lvcreate -s, что ему можно доверять? Даже при вероятности сбоя на уровне 0.1% в год я могу потерять 182 тома. С учетом того, что подобная «проблема» может происходить время от времени — то там, то здесь, будет очень тяжело диагностироваться, особенно если «проблемным» оказался снимок, а не том после blockpull/blockcommit.
В итоге, что-то может не восстановиться из резервной копии, что может существенно добавить проблем в обслуживании.
Сейчас проверка резервной копии делается легко — fsck.{ext4, xfs} volname.raw
Как этот механизм работает под нагрузкой, хотя бы вот как в описанной статье?
- Не зависит от дискового бэкенда. Диск может быть в LVM/ZFS/QCOW/NFS и тд.
- Можно вместе со снапшотом делать дамп памяти. Актуально например для серверов БД (чтобы не повреждать ее).
В вашем случае добавляется еще и возможная неконсистентность XFS при снапшоте, а значит и QCOW образов на ней. В общем что-то вы конечно восстановите, но если приложению в госте критична консистентность данных, то можно напороться. В остальном ваш способ вполне подходит для резервного бэкапа.
Насчет надежности не скажу, у нас этот способ работает на паре машин, проблем не было. Но тут конечно стоит более масштабно протестировать.
А вы уверены, что lvcreate -s надежный?) Вы же сами написали про повреждение меты LVM.
Уверены, что у вас данные всех томов правильные и в какие то случайные сектора не записалась каша (например данные снапшотов)?
В вашем случае добавляется еще и возможная неконсистентность XFS при снапшоте, а значит и QCOW образов на ней. В общем что-то вы конечно восстановите, но если приложению в госте критична консистентность данных, то можно напороться. В остальном ваш способ вполне подходит для резервного бэкапа.
lvcreate делает freeze и unfreeze файловой системы перед созданием снимка. Тут проблем нет. Это даже для бэкапа СУБД вполне применяется, например, MySQL.
Я уверен, что LVM2 значительно более надежный, чем QEMU.
Вы забываете, что я живу в оркестраторе — это не ручное управление VM на уровне Libvirt, это at scale. Там вообще нет никакого маневра, особо. Если, к примеру, узел уйдет в отрыв, когда я «снаружи» условно делаю какие-то операции мимо оркестратора, типа там снимки свои, не факт, что он мне потом не скажет — «извини, голубчик», а я пойду руками возвращать как было.
Само собой, у меня резервная копия «неконсистентная», но это минимальное зло, с учетом, что у пользователей есть весь инструментарий, которым они могут пользоваться для обеспечения необходимого уровня безопасности.
Много свободной RAM, NVMe Intel P4500 и все люто тормозит — история о неудачном добавлении раздела подкачки