LINUX.ORG.RU
Форум — Admin  

Динамически подключаемый/отключаемый SWAP


0

2

1) Представим себе ситуацию: собственного свопа не хватает, оперативка полностью забивается ресурсоёмкими процессами с высоким приоритетом, но и те процессы, которые вытесняются в своп и ещё хотят туда вытеснятся, убить oom_killer'ом просто так нельзя, иначе - убытки, головная боль, крики...
Так вот, ситуация такая: наш своп закончился, а хочется ещё. Можно, конечно, подмапить своп как блочное устройство через iSCSI. Но! В этом случае мы блокируем соответствующий лун надолго и всерьёз даже в том случае, если на самом деле нам он не нужен. Вроде бы не страшно, но это если серверов мало и полок много, а если серверов много, процессы там жирные, то полка под в 99% случаев никому не нужные свопы быстро разойдётся...
Так вот, хотелось бы, чтобы ОС принимала запрос диспетчера памяти «хочу свопа», динамически подключала свободный лун и делала из него себе дополнительный своп. Когда же своп этот опустеет, было бы неплохо возвращать его обратно в пул. Такое возможно, как вы считаете?
2) Как бы так сделать, чтобы своп располагался в файле, который может динамически расти? Обычный способ подключения свопа из файла вроде бы предполагает, что файл фиксированного размера. Или я не прав?
3) Ну и 3-й вопрос не по теме, но до кучи: а можно ли сделать так, чтобы содержимое нужного файла напрямую отображалось на страницы памяти процесса, причём при запросе реально часть этих страниц находилась бы в олеративке, а часть - на самом деле в файле. То есть последние как бы становятся разновидностью сброшенных на диск, только вместо считывания их из свопа операционная система будет читать их через обращение к драйверу ФС. Получается некий буфер файловой системы на стороне пользовательского процесса.
Я это к тому, что код, который читает файлы фиксированными блоками в оперативку, постоянно вынужден контролировать количество обработанных данных и при необходимости - дочитывать новую порцию в буфер. Ведь это могла бы делать ОС сама? Примечание: последний вопрос - для процессов, которые читают и анализируют данные «подряд» (архиваторов, разновидности grep'а и пр.)

★★★★★

Последнее исправление: DRVTiny (всего исправлений: 1)

Ответ на: комментарий от anonymous

8) Это на какой из вопросов ответ?

DRVTiny ★★★★★
() автор топика

в первом случае лучше скрипта регулярно анализирующего вывод free например, и делающего swapon -p/swapoff device по достижению определенных тобой лимитов использования не придумывается

vsemprivet ★
()

> Представим себе ситуацию: собственного свопа не хватает.

1.Сложно представить, если честно. Если своп сделан изначально как надо - в 2-3-4 раза больше оперативки, то даже если его не хватает, увеличение свопа приведет только к увеличению тормозов системы. В любом случае, чем вас не устраивает swapon/swapoff + скрипты.

2.Нет, файл со свопом на лету расти не может. Можно сделать несколько небольших файлов и подключать/отключать по мере необходимости.

3.Э-э... Вы таки не слышали про mmap? Насколько я знаю, даже вызовы типа read/write на самом деле работают через отображение ядром дисковых блоков в кэш, причем уже давно, вроде-бы еще в 2.2 так начали делать.

no-such-file ★★★★★
()

Многабуков, ниасилил. Тебе swapd чтоле нужен? Ставь altlinux, там это есть.

sin_a ★★★★★
()

это всё тупиковый путь. Всем когда-то приходит такая мысль. А такое просто не нужно потому что если всё в свопе то система большую часть времени тормозит а не работает. Это очень тупой путь забить сеть или нагрузить харды. Лучше оперативы добавить и приложения оптимизировать.

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

Ты там не «облачной» фигнёй занялся? Как правило такие вопросы на хостинге возникают...

true_admin ★★★★★
()
Ответ на: комментарий от true_admin

Ага, точно, облачной фигнёй :) Но пока ещё не на хостинге.
Но самое интересное, что к этим вопросам непосредственно я пришёл, думаю над алгоритмом супер-быстрого грепа на ассемблере (с массой ограничений, но зато «летающего»). Мне бы самому такая вещь пригодилась для анализа логов, в том числе и логов >2Gb, таких к сожалению многовато... Даже fgrep тупит на таких объёмах. А если делать вещь универсальной,то придётся вообще терабайты перелопачивать...

DRVTiny ★★★★★
() автор топика
Ответ на: комментарий от no-such-file

>3.Э-э... Вы таки не слышали про mmap? Насколько я знаю, даже вызовы типа read/write на самом деле работают через отображение ядром дисковых блоков в кэш, причем уже давно, вроде-бы еще в 2.2 так начали делать.

Thanks, вот что-то подобное я и искал. Интересно, а ведь есть ограничения архитектуры на объём оперативки, а на размер файлов ограничения значительно менее жёсткие. Так как же тогда файл отобразить в память, если он не умещается в максимальный размер таблицы страниц*максимальный размер страницы (для x64)?

DRVTiny ★★★★★
() автор топика
Ответ на: комментарий от DRVTiny

В смысле: объём оперативки для одного процесса, хотя при flat-модели памяти отображение же для всех процессов одинаковое?

DRVTiny ★★★★★
() автор топика
Ответ на: комментарий от DRVTiny

Эээ, дык mmap же :)))))). И тебе

1) хватит пары метров оперативы

2) Данные будут загружены только один раз а не три(один раз с диска, второй раз в своп и третий раз из свопа)

Ну и grep --mmap :). И у меня grep логи парсил хорошо... Может у тебя паттерны каке-то сложные? И чем ты логи ведёшь? Если nginx то их можно сделать более дружественные к парсеру.

true_admin ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
Admin