Существует ли какая-либо связь между фрагментацией памяти и включением или выключением обмена в системе?

8

Один из ответов на вопрос « Нужно ли пространство подкачки, если у меня более чем достаточно оперативной памяти?» Я задался вопросом, есть ли какая-либо связь между фрагментацией памяти, измеряемой cat /proc/buddyinfo и используемой или нет свопом. Чтобы быть более конкретным, мне интересно, может ли использование swap уменьшить фрагментацию памяти. В течение нормальных дней работы с выключением в моей системе у меня есть это:

tvbox@tvbox-G31M-ES2L:~$ cat /proc/buddyinfo
Node 0, zone      DMA      3      3      4     14     16      6      2      0      0      1      0 
Node 0, zone   Normal   1564   1052    462    356    240    109     33     21      6      1      0 
Node 0, zone  HighMem     43   1972    839    285    183    109     98     34     16      0      0 
tvbox@tvbox-G31M-ES2L:~$ free
             total       used       free     shared    buffers     cached
Mem:       2053888    1821904     231984     171376     299908     812940
-/+ buffers/cache:     709056    1344832
Swap:            0          0          0

Примечание. Время работы этой системы не должно превышать 18 часов.

В более интенсивно используемой системе у меня есть это:

me@me-zippy:~$ cat /proc/buddyinfo
Node 0, zone      DMA    149    106     70     26     15      5      4      0      0      2      0 
Node 0, zone   Normal   2455   3527   4651   1421    367    157     61     19     14      3      0 
Node 0, zone  HighMem      7     43     75    266    166    162     91     43     27      0      0 
me@me-zippy:~$ free -h
             total       used       free     shared    buffers     cached
Mem:          7.4G       7.0G       351M       281M       116M       6.0G
-/+ buffers/cache:       967M       6.4G
Swap:           0B         0B         0B
me@me-zippy:~$ uptime
 12:01:49 up 3 days,  3:20,  2 users,  load average: 0.52, 0.23, 0.17

Вы заметите, что ни в одной из этих систем не включен обмен.

Старейшина Гик
источник
4
Из любопытства, почему это имеет значение, если память фрагментирована? Это не похоже на жесткий диск, где время поиска имеет значение. В любом случае память всегда будет выглядеть логически смежной в виртуальном адресном пространстве процесса, поэтому пользовательское пространство не может даже определить, фрагментирована ли память на физическом уровне. Это потому, что таблицы перевода страниц становятся более сложными?
Селада,
Хороший вопрос. Условие было поднято как причина для использования свопа. Я остаюсь скептиком, поэтому я ищу какую-либо связь между использованием подкачки и фрагментацией памяти. Я не ожидаю найти такой, но всегда готов изменить свою позицию перед лицом новой информации. Я могу в конечном итоге ответить на этот вопрос сам после дальнейшего тестирования.
Старейшина Гик

Ответы:

3

Подкачка позволяет перемещать физические страницы, в том смысле, что для страницы, используемой для одной цели, можно заменить содержимое, а затем использовать для другой цели.

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

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

  • Паравиртуализация , когда виртуальные машины решают, кому принадлежит какая физическая страница с гранулярностью, которая грубее, чем одна страница.
  • Аналогично, кластеры, в которых несколько узлов совместно используют один и тот же пул ОЗУ.
  • Память используется периферийными устройствами, которые обычно требуют больших смежных буферов.
  • Оптимизации, такие как огромные страницы .

В отсутствие «сложных» сценариев фрагментация физической памяти может привести к проблемам с подключением нового устройства, для которого требуется пул смежной памяти (для этого в ядре такие пулы сохраняются, но их может потребоваться увеличить, если драйвер внезапно увеличит объем памяти). запрос). Если использование устройства является постоянным, физическая фрагментация не будет иметь значения и, в частности, не приведет к замедлению работы приложения или нехватке места.

Возможно, что фрагментация физического адресного пространства может привести к тому, что в ядре будет использоваться больше памяти для представления свободного списка. Я не верю, что это так в Linux, но я далеко не эксперт по управлению памятью.

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

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

Тем не менее, возможно, что добавление свопа к машине будет иметь косвенное влияние на фрагментацию в пространстве виртуальной памяти приложения. Если в системе не хватает виртуальной памяти, приложению придется делать то, что у него есть. Если приложение использует большую часть памяти, выделенной ему операционной системой, это со временем приведет к фрагментации внутри этого пространства, поскольку небольшие блоки освобождаются здесь и там. Если у приложения больше виртуальной памяти (часть из которой выгружена), это дает менеджеру памяти больше места для маневрирования и снижает риск того, что приложению не хватит памяти, при наличии трех отдельных блоков по 2 КБ, когда требуется один 4 КБ объект.

Жиль "ТАК - перестань быть злым"
источник
Разве не интересно, как каждый ответ приводит к новому вопросу? Теперь мне интересно узнать порядок операций управления памятью и какие методы освобождения памяти должны завершиться неудачей до достижения состояния нехватки памяти. Мое предположение, что кеш является наименее важным и будет сброшен первым. Я знаю, что где-то здесь есть доля правды (каламбур). ;-)
Старейшина Гик
@ElderGeek - Документация / cgroups / memory.txt , вероятно, является хорошим местом для начала. Хотя он безнадежно устарел, он довольно хорошо просматривает контроллер памяти ядра.
mikeserv
@mikeserv Спасибо за это. Я также нашел - landley.net/writing/memory-faq.txt, который также выглядит «безнадежно устаревшим», но, по крайней мере, мне кажется, что моя теория относительно логического сброса кеша сначала освобождает ОЗУ, прежде чем прибегнуть к убийству. процессы точны. Я сомневаюсь, что узнаю об этом намного больше, не углубляясь в сам код. Это может быть немного за пределами моего понимания, поскольку я десятилетиями не писал никакого кода, кроме сценариев bash ...
Старейшина Гик