Ситуация с Linux (32-битное ядро)

Question 1

Однако радикальным подходом было бы обновление до 64-битной ОС (в данном случае 32-битной), поскольку компоновка зон выполнена по-другому.

Хорошо, так что здесь я попытаюсь ответить, почему вы испытали OOM здесь. Здесь есть ряд факторов.

Размер заказа в запросе и то, как ядро обрабатывает определенные размеры заказов.
Выбранная зона.
Водяные знаки, используемые в этой зоне.
Фрагментация в зоне.

Если посмотреть на сам OOM, то там явно много свободной памяти, но OOM-killer был вызван? Почему?

Размер заказа в запросе и то, как ядро обрабатывает определенные размеры заказов

Ядро выделяет память по порядку. «Порядок» — это область непрерывной оперативной памяти, которая должна быть удовлетворена для выполнения запроса. Порядки упорядочиваются по порядку величины (отсюда и название «порядок») с помощью алгоритма 2^(ORDER + 12). Так, порядок 0 — это 4096, порядок 1 — это 8192, порядок 2 — это 16384 и т. д. и т. п.

В ядре жестко закодировано значение того, что считается «высоким порядком» (> PAGE_ALLOC_COSTLY_ORDER). Это порядок 4 и выше (64 Кб и выше — это высокий порядок).

Высокие порядки удовлетворяются для выделения страниц иначе, чем низкие порядки. Выделение высокого порядка, если оно не может захватить память, на современных ядрах будет.

Попробуйте запустить процедуру уплотнения памяти, чтобы дефрагментировать память.
Никогдапозвоните OOM-killer, чтобы удовлетворить запрос.

Размер вашего заказа указан здесь

Dec 27 09:19:05 2013 kernel: : [277622.359064] squid invoked oom-killer: gfp_mask=0x42d0, order=3, oom_score_adj=0

Заказ 3 является наивысшим из запросов низшего порядка и (как вы видите) вызывает OOM-killer в попытке его удовлетворить.

Обратите внимание, что большинство распределений пространства пользователя не используют запросы высокого порядка. Обычно ядро требует непрерывных областей памяти. Исключением может быть случай, когда пространство пользователя использует hugepages, но в данном случае это не так.

В вашем случае выделение порядка 3 вызывается ядром, желающим поставить пакет в очередь сетевого стека — для этого требуется выделение 32 КБ.

Выбранная зона.

Ядро делит ваши регионы памяти на зоны. Это разделение выполняется потому, что на x86 определенные регионы памяти адресуются только определенным оборудованием. Например, старое оборудование может адресовать память только в зоне 'DMA'. Когда мы хотим выделить некоторую память, сначала выбирается зона итолькоСвободная память этой зоны учитывается при принятии решения о распределении.

Хотя я не совсем разбираюсь в алгоритме выбора зоны, типичный вариант использования — никогда не выделять память из DMA, а выбирать зону с наименьшим адресуемым адресом, которая может удовлетворить запрос.

Во время OOM выдается много информации о зонах, которую также можно почерпнуть из /proc/zoneinfo.

Dec 27 09:19:05 2013 kernel: : [277622.359382] DMA free:2332kB min:36kB low:44kB high:52kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15968kB managed:6960kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:8kB slab_unreclaimable:288kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? yes
Dec 27 09:19:05 2013 kernel: : [277622.359393] Normal free:114488kB min:3044kB low:3804kB high:4564kB active_anon:0kB inactive_anon:0kB active_file:252kB inactive_file:256kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:894968kB managed:587540kB mlocked:0kB dirty:0kB writeback:0kB mapped:4kB shmem:0kB slab_reclaimable:117712kB slab_unreclaimable:138616kB kernel_stack:11976kB pagetables:0kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:982 all_unreclaimable? yes
Dec 27 09:19:05 2013 kernel: : [277622.359404] HighMem free:27530668kB min:512kB low:48272kB high:96036kB active_anon:2634060kB inactive_anon:217596kB active_file:4688452kB inactive_file:1294168kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:36828872kB managed:36828872kB mlocked:0kB dirty:0kB writeback:0kB mapped:183132kB shmem:39400kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:430856kB unstable:0kB bounce:367564104kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no

Зоны, которые у вас есть, DMA, Normal и HighMem, указывают на 32-битную платформу, поскольку зона HighMem отсутствует на 64-битной. Также на 64-битных системах Normal отображается на 4 ГБ и больше, тогда как на 32-битной она отображается на 896 МБ (хотя в вашем случае ядро сообщает об управлении только меньшей частью, чем эта:- managed:587540kB.)

Можно сказать, откуда взялось это распределение, снова посмотрев на первую строку, gfp_mask=0x42d0она сообщает нам, какой тип распределения был выполнен. Последний байт (0) говорит нам, что это распределение из нормальной зоны. Значения gfp находятся ввключить/linux/gfp.h.

Водяные знаки, используемые в этой зоне.

Когда памяти мало, действия по ее освобождению определяются водяным знаком. Они отображаются здесь: min:3044kB low:3804kB high:4564kB. Если свободной памяти становится «низко», то подкачка будет происходить до тех пор, пока мы не преодолеем порог «высоко». Если памяти становится «мин», нам нужно убить все, чтобы освободить память с помощью OOM-killer.

Фрагментация в зоне.

Чтобы увидеть, может ли быть удовлетворен запрос на определенный заказ памяти, ядро учитывает, сколько свободных страниц и доступно для каждого заказа. Это можно прочитать в /proc/buddyinfo. Отчеты OOM-killer дополнительно выдают buddyinfo, как показано здесь:

Normal: 5360*4kB (UEM) 3667*8kB (UEM) 3964*16kB (UEMR) 13*32kB (MR) 0*64kB 1*128kB (R) 1*256kB (R) 0*512kB 0*1024kB 0*2048kB 0*4096kB = 115000kB

Для того, чтобы распределение памяти было выполнено тамдолженбыть свободной памяти, доступной в запрошенном размере порядка или более высоком выделении. Наличие большого количества свободных данных в нижних порядках и ни одного в верхних порядках означает, что ваша память фрагментирована. Если вы получаете очень высокое выделение порядка, возможно (даже при большом количестве свободной памяти), что оно не будет удовлетворено из-за отсутствия доступных страниц высокого порядка. Ядро может дефрагментировать память (это называется уплотнением памяти), перемещая множество страниц низкого порядка так, чтобы они не оставляли пробелов в адресуемом пространстве ОЗУ.

OOM-killer был вызван? Почему?

Итак, если принять это во внимание, то можно сказать следующее:

Была предпринята попытка непрерывного выделения 32 КБ из нормальной зоны.
В выбранной зоне было достаточно свободной памяти.
Была доступна память порядка 3, 5 и 6.13*32kB (MR) 1*128kB (R) 1*256kB (R)

Итак, если естьбылсвободная память, другие заказымогудовлетворить просьбу. что случилось?

Ну, выделение из заказа — это нечто большее, чем просто проверка объема свободной памяти, доступной для этого заказа или выше. Ядро фактически вычитает память из всех нижних заказов из общей свободной строки, а затем выполняет проверку минимального водяного знака на том, что осталось.

В вашем случае происходит проверка нашей свободной памяти для той зоны, которую мы должны сделать.

115000 - (5360*4) - (3667*8) - (3964*16) = 800

Этот объем свободной памяти проверяется по minводяному знаку, который равен 3044. Таким образом, технически говоря, у вас не осталось свободной памяти для запрошенного вами выделения. И вот почему вы вызвали OOM-killer.

Фиксация

Есть два исправления. Обновление до 64 бит изменяет разбиение зон таким образом, что «Обычный» составляет от 4 ГБ до 36 ГБ, поэтому вам не придется «по умолчанию» выделять память в зону, которая может быть сильно фрагментирована. Проблема решается не тем, что у вас больше адресуемой памяти (потому что вы уже используете PAE), а тем, что выбранная вами зона имеет больше адресуемой памяти.

Второй способ (который я никогда не тестировал) — попытаться заставить ядро более агрессивно сжимать вашу память.

Если вы измените значение vm.extfrag_thresholdс 500 на 100, то, скорее всего, произойдет сжатие памяти в попытке выполнить выделение высокого порядка. Хотя я никогда раньше не имел дела с этим значением — оно также будет зависеть от того, какой у вас индекс фрагментации, который доступен в /sys/kernel/debug/extfrag/extfrag_index. У меня сейчас нет коробки с достаточно новым ядром, чтобы посмотреть, что это может предложить сверх этого.

В качестве альтернативы вы можете запустить какое-нибудь задание cron (это ужасно, ужасно уродливо), чтобы вручную сжать память, записав данные в /proc/sys/vm/compact_memory.

Но, честно говоря, я не думаю, что есть способ настроить систему так, чтобы избежать этой проблемы — это природа распределителя памяти, которая работает таким образом. Изменение архитектуры используемой вами платформы, вероятно, является единственным принципиально разрешимым решением.

Answer

Однако радикальным подходом было бы обновление до 64-битной ОС (в данном случае 32-битной), поскольку компоновка зон выполнена по-другому.

Хорошо, так что здесь я попытаюсь ответить, почему вы испытали OOM здесь. Здесь есть ряд факторов.

Размер заказа в запросе и то, как ядро обрабатывает определенные размеры заказов.
Выбранная зона.
Водяные знаки, используемые в этой зоне.
Фрагментация в зоне.

Если посмотреть на сам OOM, то там явно много свободной памяти, но OOM-killer был вызван? Почему?

Размер заказа в запросе и то, как ядро обрабатывает определенные размеры заказов

Ядро выделяет память по порядку. «Порядок» — это область непрерывной оперативной памяти, которая должна быть удовлетворена для выполнения запроса. Порядки упорядочиваются по порядку величины (отсюда и название «порядок») с помощью алгоритма 2^(ORDER + 12). Так, порядок 0 — это 4096, порядок 1 — это 8192, порядок 2 — это 16384 и т. д. и т. п.

В ядре жестко закодировано значение того, что считается «высоким порядком» (> PAGE_ALLOC_COSTLY_ORDER). Это порядок 4 и выше (64 Кб и выше — это высокий порядок).

Высокие порядки удовлетворяются для выделения страниц иначе, чем низкие порядки. Выделение высокого порядка, если оно не может захватить память, на современных ядрах будет.

Попробуйте запустить процедуру уплотнения памяти, чтобы дефрагментировать память.
Никогдапозвоните OOM-killer, чтобы удовлетворить запрос.

Размер вашего заказа указан здесь

Dec 27 09:19:05 2013 kernel: : [277622.359064] squid invoked oom-killer: gfp_mask=0x42d0, order=3, oom_score_adj=0

Заказ 3 является наивысшим из запросов низшего порядка и (как вы видите) вызывает OOM-killer в попытке его удовлетворить.

Обратите внимание, что большинство распределений пространства пользователя не используют запросы высокого порядка. Обычно ядро требует непрерывных областей памяти. Исключением может быть случай, когда пространство пользователя использует hugepages, но в данном случае это не так.

В вашем случае выделение порядка 3 вызывается ядром, желающим поставить пакет в очередь сетевого стека — для этого требуется выделение 32 КБ.

Выбранная зона.

Ядро делит ваши регионы памяти на зоны. Это разделение выполняется потому, что на x86 определенные регионы памяти адресуются только определенным оборудованием. Например, старое оборудование может адресовать память только в зоне 'DMA'. Когда мы хотим выделить некоторую память, сначала выбирается зона итолькоСвободная память этой зоны учитывается при принятии решения о распределении.

Хотя я не совсем разбираюсь в алгоритме выбора зоны, типичный вариант использования — никогда не выделять память из DMA, а выбирать зону с наименьшим адресуемым адресом, которая может удовлетворить запрос.

Во время OOM выдается много информации о зонах, которую также можно почерпнуть из /proc/zoneinfo.

Dec 27 09:19:05 2013 kernel: : [277622.359382] DMA free:2332kB min:36kB low:44kB high:52kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15968kB managed:6960kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:8kB slab_unreclaimable:288kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? yes
Dec 27 09:19:05 2013 kernel: : [277622.359393] Normal free:114488kB min:3044kB low:3804kB high:4564kB active_anon:0kB inactive_anon:0kB active_file:252kB inactive_file:256kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:894968kB managed:587540kB mlocked:0kB dirty:0kB writeback:0kB mapped:4kB shmem:0kB slab_reclaimable:117712kB slab_unreclaimable:138616kB kernel_stack:11976kB pagetables:0kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:982 all_unreclaimable? yes
Dec 27 09:19:05 2013 kernel: : [277622.359404] HighMem free:27530668kB min:512kB low:48272kB high:96036kB active_anon:2634060kB inactive_anon:217596kB active_file:4688452kB inactive_file:1294168kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:36828872kB managed:36828872kB mlocked:0kB dirty:0kB writeback:0kB mapped:183132kB shmem:39400kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:430856kB unstable:0kB bounce:367564104kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no

Зоны, которые у вас есть, DMA, Normal и HighMem, указывают на 32-битную платформу, поскольку зона HighMem отсутствует на 64-битной. Также на 64-битных системах Normal отображается на 4 ГБ и больше, тогда как на 32-битной она отображается на 896 МБ (хотя в вашем случае ядро сообщает об управлении только меньшей частью, чем эта:- managed:587540kB.)

Можно сказать, откуда взялось это распределение, снова посмотрев на первую строку, gfp_mask=0x42d0она сообщает нам, какой тип распределения был выполнен. Последний байт (0) говорит нам, что это распределение из нормальной зоны. Значения gfp находятся ввключить/linux/gfp.h.

Водяные знаки, используемые в этой зоне.

Когда памяти мало, действия по ее освобождению определяются водяным знаком. Они отображаются здесь: min:3044kB low:3804kB high:4564kB. Если свободной памяти становится «низко», то подкачка будет происходить до тех пор, пока мы не преодолеем порог «высоко». Если памяти становится «мин», нам нужно убить все, чтобы освободить память с помощью OOM-killer.

Фрагментация в зоне.

Чтобы увидеть, может ли быть удовлетворен запрос на определенный заказ памяти, ядро учитывает, сколько свободных страниц и доступно для каждого заказа. Это можно прочитать в /proc/buddyinfo. Отчеты OOM-killer дополнительно выдают buddyinfo, как показано здесь:

Normal: 5360*4kB (UEM) 3667*8kB (UEM) 3964*16kB (UEMR) 13*32kB (MR) 0*64kB 1*128kB (R) 1*256kB (R) 0*512kB 0*1024kB 0*2048kB 0*4096kB = 115000kB

Для того, чтобы распределение памяти было выполнено тамдолженбыть свободной памяти, доступной в запрошенном размере порядка или более высоком выделении. Наличие большого количества свободных данных в нижних порядках и ни одного в верхних порядках означает, что ваша память фрагментирована. Если вы получаете очень высокое выделение порядка, возможно (даже при большом количестве свободной памяти), что оно не будет удовлетворено из-за отсутствия доступных страниц высокого порядка. Ядро может дефрагментировать память (это называется уплотнением памяти), перемещая множество страниц низкого порядка так, чтобы они не оставляли пробелов в адресуемом пространстве ОЗУ.

OOM-killer был вызван? Почему?

Итак, если принять это во внимание, то можно сказать следующее:

Была предпринята попытка непрерывного выделения 32 КБ из нормальной зоны.
В выбранной зоне было достаточно свободной памяти.
Была доступна память порядка 3, 5 и 6.13*32kB (MR) 1*128kB (R) 1*256kB (R)

Итак, если естьбылсвободная память, другие заказымогудовлетворить просьбу. что случилось?

Ну, выделение из заказа — это нечто большее, чем просто проверка объема свободной памяти, доступной для этого заказа или выше. Ядро фактически вычитает память из всех нижних заказов из общей свободной строки, а затем выполняет проверку минимального водяного знака на том, что осталось.

В вашем случае происходит проверка нашей свободной памяти для той зоны, которую мы должны сделать.

115000 - (5360*4) - (3667*8) - (3964*16) = 800

Этот объем свободной памяти проверяется по minводяному знаку, который равен 3044. Таким образом, технически говоря, у вас не осталось свободной памяти для запрошенного вами выделения. И вот почему вы вызвали OOM-killer.

Фиксация

Есть два исправления. Обновление до 64 бит изменяет разбиение зон таким образом, что «Обычный» составляет от 4 ГБ до 36 ГБ, поэтому вам не придется «по умолчанию» выделять память в зону, которая может быть сильно фрагментирована. Проблема решается не тем, что у вас больше адресуемой памяти (потому что вы уже используете PAE), а тем, что выбранная вами зона имеет больше адресуемой памяти.

Второй способ (который я никогда не тестировал) — попытаться заставить ядро более агрессивно сжимать вашу память.

Если вы измените значение vm.extfrag_thresholdс 500 на 100, то, скорее всего, произойдет сжатие памяти в попытке выполнить выделение высокого порядка. Хотя я никогда раньше не имел дела с этим значением — оно также будет зависеть от того, какой у вас индекс фрагментации, который доступен в /sys/kernel/debug/extfrag/extfrag_index. У меня сейчас нет коробки с достаточно новым ядром, чтобы посмотреть, что это может предложить сверх этого.

В качестве альтернативы вы можете запустить какое-нибудь задание cron (это ужасно, ужасно уродливо), чтобы вручную сжать память, записав данные в /proc/sys/vm/compact_memory.

Но, честно говоря, я не думаю, что есть способ настроить систему так, чтобы избежать этой проблемы — это природа распределителя памяти, которая работает таким образом. Изменение архитектуры используемой вами платформы, вероятно, является единственным принципиально разрешимым решением.

Question 2

Для начала: вам следуетДействительноперейти на 64-битную операционную систему. У вас есть веская причина остаться на 32-битной версии?

Трудно диагностировать эту проблему, не посмотрев на систему более внимательно, желательно в момент сбоя, поэтому мой (быстрый) пост более или менее в общем направлен на проблемы с памятью в 32-битных системах. Я уже говорил, что переход на 64-битную версию заставит все это исчезнуть?

Ваша проблема тройная.

Во-первых, даже на ядре PAE адресное пространство на процесс ограничено 4GiB[1]. Это означает, что ваш экземпляр squid никогда не сможет съесть больше 4GiB RAM на процесс. Я не очень хорошо знаком со squid, но если это ваш основной прокси-сервер, этого может быть недостаточно.

Во-вторых, в 32-битной системе с огромным объемом оперативной памяти много памяти в так называемой «ZONE_NORMAL» используется для хранения структур данных, которые необходимы для использования памяти в ZONE_HIGHMEM. Эти структуры данных не могут быть перемещены в ZONE_HIGHMEM сами по себе, потому что память, которую ядро использует для своих собственных целей, всегда должна находиться в ZONE_NORMAL (т.е. в первых 1GiB-ish). Чем больше памяти у вас в ZONE_HIGHMEM (много, в вашем случае), тем больше это становится проблемой, потому что ядру затем требуется все больше и больше памяти из ZONE_NORMAL для управления ZONE_HIGHMEM. По мере того, как объем свободной памяти в ZONE_NORMAL иссякает, ваша система может давать сбой при выполнении некоторых задач, потому что ZONE_NORMAL — это то место, гдемноговещей происходит на 32-битной системе. Все операции с памятью, связанные с ядром, например ;)

В-третьих, даже если в ZONE_NORMAL осталась какая-то память (я не изучал ваши логи подробно), некоторые операции с памятью потребуют нефрагментированной памяти. Например, если вся ваша память фрагментирована на очень маленькие части, некоторые операции, которым нужно больше, потерпят неудачу. [3] Беглый взгляд на ваши логи показывает довольно значительную фрагментацию в ZONE_DMA и ZONE_NORMAL.

Редактировать: Ответ Mlfe выше содержит превосходное подробное объяснение того, как это работает.

Еще раз: на 64-битной системе вся память находится в ZONE_NORMAL. Зоны HIGHMEM на 64-битных системах нет. Проблема решена.

Редактировать: Вы можете взглянуть сюда [4], чтобы узнать, можете ли вы сказать oom-killer оставить ваши важные процессы в покое. Это не решит всего (если вообще что-то решит), но это может стоить попробовать.

[1]http://en.wikipedia.org/wiki/Расширение_физического_адреса#Дизайн

[2]http://www.redhat.com/archives/rhelv5-list/2008-September/msg00237.htmlиhttps://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/5/html/Настройка_и_оптимизация_Red_Hat_Enterprise_Linux_для_Oracle_9i_and_10g_баз_данных/sect-Oracle_9i_and_10g_Руководство_по_настройке_аппаратных_архитектур_и_ядер_Linux-a32_bit_Architecture_and_the_hugemem_Kernel.html

[3]http://bl0rg.krunch.be/oom-frag.html

[4]http://lwn.net/Articles/317814/

Answer

Для начала: вам следуетДействительноперейти на 64-битную операционную систему. У вас есть веская причина остаться на 32-битной версии?

Трудно диагностировать эту проблему, не посмотрев на систему более внимательно, желательно в момент сбоя, поэтому мой (быстрый) пост более или менее в общем направлен на проблемы с памятью в 32-битных системах. Я уже говорил, что переход на 64-битную версию заставит все это исчезнуть?

Ваша проблема тройная.

Во-первых, даже на ядре PAE адресное пространство на процесс ограничено 4GiB[1]. Это означает, что ваш экземпляр squid никогда не сможет съесть больше 4GiB RAM на процесс. Я не очень хорошо знаком со squid, но если это ваш основной прокси-сервер, этого может быть недостаточно.

Во-вторых, в 32-битной системе с огромным объемом оперативной памяти много памяти в так называемой «ZONE_NORMAL» используется для хранения структур данных, которые необходимы для использования памяти в ZONE_HIGHMEM. Эти структуры данных не могут быть перемещены в ZONE_HIGHMEM сами по себе, потому что память, которую ядро использует для своих собственных целей, всегда должна находиться в ZONE_NORMAL (т.е. в первых 1GiB-ish). Чем больше памяти у вас в ZONE_HIGHMEM (много, в вашем случае), тем больше это становится проблемой, потому что ядру затем требуется все больше и больше памяти из ZONE_NORMAL для управления ZONE_HIGHMEM. По мере того, как объем свободной памяти в ZONE_NORMAL иссякает, ваша система может давать сбой при выполнении некоторых задач, потому что ZONE_NORMAL — это то место, гдемноговещей происходит на 32-битной системе. Все операции с памятью, связанные с ядром, например ;)

В-третьих, даже если в ZONE_NORMAL осталась какая-то память (я не изучал ваши логи подробно), некоторые операции с памятью потребуют нефрагментированной памяти. Например, если вся ваша память фрагментирована на очень маленькие части, некоторые операции, которым нужно больше, потерпят неудачу. [3] Беглый взгляд на ваши логи показывает довольно значительную фрагментацию в ZONE_DMA и ZONE_NORMAL.

Редактировать: Ответ Mlfe выше содержит превосходное подробное объяснение того, как это работает.

Еще раз: на 64-битной системе вся память находится в ZONE_NORMAL. Зоны HIGHMEM на 64-битных системах нет. Проблема решена.

Редактировать: Вы можете взглянуть сюда [4], чтобы узнать, можете ли вы сказать oom-killer оставить ваши важные процессы в покое. Это не решит всего (если вообще что-то решит), но это может стоить попробовать.

[1]http://en.wikipedia.org/wiki/Расширение_физического_адреса#Дизайн

[2]http://www.redhat.com/archives/rhelv5-list/2008-September/msg00237.htmlиhttps://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/5/html/Настройка_и_оптимизация_Red_Hat_Enterprise_Linux_для_Oracle_9i_and_10g_баз_данных/sect-Oracle_9i_and_10g_Руководство_по_настройке_аппаратных_архитектур_и_ядер_Linux-a32_bit_Architecture_and_the_hugemem_Kernel.html

[3]http://bl0rg.krunch.be/oom-frag.html

[4]http://lwn.net/Articles/317814/

Question 3

@MIfe уже предоставилотличная статья о том, как обрабатывается распределение памяти в ядреа также предоставил вам правильное решение, такое как переход на 64-битную ОС, и неприятный хак, такой как ручное сжатие памяти /proc/sys/vm/compact_memoryчерез cron.

Мои 2 цента будут еще одним обходным путем, который может вам помочь:
я заметил, что у вас tcp_tso_segmentв ядре есть обратная трассировка, поэтому делаю так:

# ethtool -K ethX tso off gso off lro off

можно уменьшить давление, mmзаставив его использовать более низкие порядки.

ПС. список всех разгрузок можно получить через# ethtool -k ethX

Answer

@MIfe уже предоставилотличная статья о том, как обрабатывается распределение памяти в ядреа также предоставил вам правильное решение, такое как переход на 64-битную ОС, и неприятный хак, такой как ручное сжатие памяти /proc/sys/vm/compact_memoryчерез cron.

Мои 2 цента будут еще одним обходным путем, который может вам помочь:
я заметил, что у вас tcp_tso_segmentв ядре есть обратная трассировка, поэтому делаю так:

# ethtool -K ethX tso off gso off lro off

можно уменьшить давление, mmзаставив его использовать более низкие порядки.

ПС. список всех разгрузок можно получить через# ethtool -k ethX

Question 4

Паника возникает из-за установки sysctl "vm.panic_on_oom = 1" — идея в том, что перезагрузка системы возвращает ее в нормальное состояние. Вы можете изменить это в sysctl.conf.

Прямо вверху мы читаем squid invoked oom killer. Вы можете проверить конфигурацию squid и его максимальное использование памяти (или просто перейти на 64-битную ОС).

/proc/meminfo показывает, что используется зона высокой памяти, поэтому вы используете 32-битное ядро с 36 ГБ памяти. Вы также можете видеть, что в нормальной зоне, чтобы удовлетворить потребность squid в памяти, ядро безуспешно просканировало 982 страницы:

pages_scanned:982 all_unreclaimable? yes

Answer

Паника возникает из-за установки sysctl "vm.panic_on_oom = 1" — идея в том, что перезагрузка системы возвращает ее в нормальное состояние. Вы можете изменить это в sysctl.conf.

Прямо вверху мы читаем squid invoked oom killer. Вы можете проверить конфигурацию squid и его максимальное использование памяти (или просто перейти на 64-битную ОС).

/proc/meminfo показывает, что используется зона высокой памяти, поэтому вы используете 32-битное ядро с 36 ГБ памяти. Вы также можете видеть, что в нормальной зоне, чтобы удовлетворить потребность squid в памяти, ядро безуспешно просканировало 982 страницы:

pages_scanned:982 all_unreclaimable? yes

Ситуация с Linux (32-битное ядро)

решение1

Размер заказа в запросе и то, как ядро обрабатывает определенные размеры заказов

Выбранная зона.

Водяные знаки, используемые в этой зоне.

Фрагментация в зоне.

OOM-killer был вызван? Почему?

Фиксация

решение2

решение3

решение4

Связанный контент

решение1

Размер заказа в запросе и то, как ядро ​​обрабатывает определенные размеры заказов

Выбранная зона.

Водяные знаки, используемые в этой зоне.

Фрагментация в зоне.

OOM-killer был вызван? Почему?

Фиксация

решение2

решение3

решение4

Связанный контент

Размер заказа в запросе и то, как ядро обрабатывает определенные размеры заказов