SWAP файл в Ubuntu Server. Повышаем выносливость


Для всех, кто более или менее знаком с работой современных операционных систем, не секрет, что при нехватке оперативной памяти оные начинают свопаться. Это значит, что часть данных, которая хранится в оперативной памяти (наиболее не значимая на данных момент) выгружается на специальную область диска. В Linux based системах для этого дела создается (при установке) специальный раздел на диске. В Win имеется файл в корне системы. В общем, эта практика активно используется.

Что касается рабочих ПК, то тут никто не мешает вам поставить такой объем памяти, что хватит на то, чтобы всю систему в нее выгрузить 🙂 Что же касается серверных систем, то тут ситуация двоякая. Потому, что классически архитектура (распределенная) может строиться либо с вертикальном масштабированием (берем сервер со 126 Гб памяти!), либо с горизонтальным (берем 10 машин по 12 ГБ!). Для каждой задачи свой принцип предпочтительнее.

К чему это я? Да к тому, что сейчас довольно популярно делать именно системы с горизонтальной масштабируемостью, отчасти по причине широкой популярности облаков. Мощь достигается десятками «машинок» распределенных географически. Получаем параллельность потоков обработки данных, распределенность ну и более или менее отказоустойчивость (все, конечно, соответственно CAP теоремы 🙂 ).

Ввиду этого, в последнее время для «продвинутых» сайтовладельцев все слаще использование микро-инстансев амазона, ну или пятидолларового дроплетов от моего любимого DO. Однако, в некоторых ситуациях с таким сервером могут возникнуть проблемы. Например, не хватит памяти для обработки какой-нибудь разухабистой таблицы СУБД.

Возвращаемся в SWAP. Итак, во времена обычных HDD выгрузка в своп доставляет проблемы, а именно — очень медленное чтение информации с диска потом, когда она становится нужной. Другой вопрос, когда у вас под рукой высокой производительный RAID или (еще лучше) SSD. Так вот, если у нас микро сервер, для обеспечения более отказоустойчивой работы, можно использовать SWAP, это будет вполне себе быстро.

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

Приступим.

Вот и все. Как видите просто и доступно, а в итоге спать можно немного спокойнее и не поглядывать на вашу систему мониторинга.


  • Спасибо! Cделал swap по Вашей инструкции. Перестала ежесуточно падать MySQL. Сервер Ubuntu 13.10 на DO. Хотя, наверное, в моем случае — это просто запасной вариант, а не решение проблемы. Десяток сайтов WordPress съедают непозволительно много оперативки, несмотря на наличие кэширующих плагинов…

    • Всегда пожалуйста 🙂 Смотрите конфиг мускула на предмет кеширования запросов. И ставьте memcached, apc — через плагин W3 Total Cache можно кешировать объекты и запросы.

      А еще я бы посоветовал вам поставить varnish как бэкэнд. Правда придется повозиться с настройкой.

      • Установлен Xcache, на всех WordPress сайтах плагины типа Tribe Object Cache, Hyper Cache. А картина все равно примерно такова:

        • А какие именно демоны съедают больше всего памяти? Скиньте раскладку. И как реализована обработка запросов? Есть фронт/бэкенд? И какова статистика по запросам в секунду, средняя?

          • nginx (как фронтенд для отдачи статики) + Apache (как бекенд для обработки php) + php 5.3.x

            Как-то так…

          • Мда, селектов много. А какие значения в query_cache_size и query_cache_limit? И включено ли кеширование (query_cache_type = ON)?

          • query_cache_limit = 16M
            query_cache_size = 128M
            По Вашему совету добавил query_cache_type = ON в my.cnf — никакого результата…

          • Норм. Кеширование запросов позволит мускулу не расходовать больше памяти своими воркерами. А вообще, по расходу памяти надо смотреть поглубже. На днях напишу, думаю, статейку на эту тему.