У меня огромная проблема с кешем страниц Linux, который замедляет ввод-вывод. Например, если я копирую раздел lvm с помощью dd, linux кэширует данные в буферах или кешах (бесплатно –m). Это не проблема, но после того, как буфер достигает особого значения, процесс копирования останавливается и замедляется до нескольких мегабайт или даже килобайт. Я провел много тестов с записью на диск или / dev / null, проблема не имеет ничего общего с исходным диском или местом назначения.
В деталях:
Вывод:
Проблема связана либо со вторым процессором, либо с общим объемом памяти. У меня есть «ощущение», что проблема может заключаться в том, что каждый процессор имеет свою собственную оперативную память объемом 32 ГБ, а процесс копирования выполняется только на центральном процессоре. Итак, наконец, процесс копирования увеличил буфер / кеш почти до 32 ГБ или до неиспользуемой памяти другого процессора, а затем Linux думает, что есть еще память, поэтому позволяет нам увеличивать буфер дальше, но оборудование ниже не может получить доступ к памяти или что-то еще как это.
Есть у кого-нибудь идея или решение? Конечно, я могу использовать dd с прямым флагом, но это не решает проблему, потому что есть также внешний доступ через самбу и так далее.
РЕДАКТИРОВАТЬ1:
Здесь также / proc / zoneinfo с 64-гигабайтного RAM-сервера: 1. http://pastebin.com/uSnpQbeD (перед запуском dd) 2. http://pastebin.com/18YVTfdb (когда дд перестанет работать)
РЕДАКТИРОВАТЬ2:
РЕДАКТИРОВАТЬ3:
/ proc / buddyinfo и numactl --hardware: http://pastebin.com/0PmXxxin
КОНЕЧНЫЙ РЕЗУЛЬТАТ
Поведение, которое вы видите, связано с тем, как Linux выделяет память в системе NUMA.
Я предполагаю (не зная), что система на 32 ГБ не является numa или недостаточно numa для Linux.
То, как обращаться с нумой, продиктовано /proc/sys/vm/zone_reclaim_mode вариант. По умолчанию Linux определит, используете ли вы систему numa, и изменит флаги восстановления, если сочтет, что это даст лучшую производительность.
Память разделена на зоны, в системе numa есть зона для первого сокета процессора и зона для второго. Они выглядят как node0 и node1. Вы можете увидеть их, если вы кошка /proc/buddyinfo.
Когда для режима восстановления зоны установлено значение 1, выделение из первого сокета ЦП вызовет восстановление в зоне памяти, связанной с этим ЦП, потому что более эффективно с точки зрения производительности восстановление из локального узла numa. Восстановление в этом смысле означает отбрасывание страниц, например очистку кеша или замену содержимого на этом узле.
Установка значения 0 приводит к тому, что восстановление не происходит, если зона заполняется, вместо этого происходит выделение в чужие зоны numa для памяти. Это происходит за счет блокировки другого ЦП для получения монопольного доступа к этой зоне памяти.
Но тут моментально начнется свопинг! через несколько секунд: Mem: всего 66004536k, использовано 65733796k, 270740k бесплатно, 34250384k буферов Swap: всего 10239992k, используется 1178820k, 9061172k бесплатно, 91388k кэшировано
Поведение подкачки и время подкачки определяется несколькими факторами, одним из которых является то, насколько активны страницы, выделенные приложениям. Если они не очень активны, они будут заменены на более загруженную работу, выполняемую в кэше. Я предполагаю, что страницы на ваших виртуальных машинах активируются не очень часто.
