Тогда как же решается эта проблема?

Масштабированием. В данном случае, просто переехать на нормальный хостинг.

cgroups, cpu.shares, запихнуть sshd туда?

Понятно, что-то тарилось. Кильнул его.

Ну такой себе из вас админ. Можно другого?

но это оказалось не то, приоритеты меняют только очередность выполнения задач.

это где ты такое «посмотрел» ?

cpulimit, если машинка уже не справляется.

это где ты такое «посмотрел» ?

Вот здесь - https://pc.ru/articles/kak-zadat-ili-izmenit-prioritet-processa-v-linux

cpulimit, если машинка уже не справляется.

Сорри, совсем забыл сказать - проц вполне справлялся, а вот диск - нет.

Все эти проценты были определены в iotop.
Могу выложить скрин, если скажете куда.

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

Второй вариант - cgroups, контейнеры, разделение/ограничение ресурсов. Вынесение отдельных (критических) задач на отдельные мощности / виртуальные машины. Микросервисная архитектура и т.п.

Те же яйца, только в профиль.
Запускать процессы последовательно, а не параллельно.

Написать скрипт, который будет запускать эти процессы в ручном режиме. Заходить раз в N-й период и запускать, когда не требуется выполнять никакие другие задачи.

Это не подходит, потому что эти процессы должны работать ВСЕГДА - это же вебсайт.

Второй вариант - cgroups, контейнеры, разделение/ограничение ресурсов. Вынесение отдельных (критических)....

А это уже сложно. Неужели такая типичная и относительно простая по сути задача должна решаться столь сложными методами?
Сколько уже нашему Линуксу исполнилось лет? И что, до сих пор не предусмотрели нативного встроенного решения?

PS. На всякий случай, если кто пропустил -

Сорри, совсем забыл сказать - проц вполне справлялся, а вот диск - нет.
Все эти проценты были определены в iotop.

Сорри, совсем забыл сказать - проц вполне справлялся, а вот диск - нет.

Из простого: man pv или диск нормальный. Или вышесказанное.

Это не подходит, потому что эти процессы должны работать ВСЕГДА - это же вебсайт.

Чего? Бэкапы должны работать ежесекундно? Это как вообще?

Перечитай еще раз, нет там ничего про «очередность выполнения задачи».

man nice

Сорри, совсем забыл сказать - проц вполне справлялся, а вот диск - нет.

man ionice

Вы что-то странное говорите. У меня тоже есть сервак где хостится 4 интернет-магазина с общей суточной посещаемостью от 100 до 700к уникальных пользователей. На нем все по старинке, без контейнеров и т.п. Просто раз в сутки, когда наименьшая посещаемость запускаю вручную скрипт для создания полных бэкапов. И то это чтобы случай чего сильно не усложнить работу менеджеров. Для синхронизации изменений кодовой базы там обычно минимальные ресурсы требуются, от считанных секунд работы процессорного времени.

Чтобы бэкапы делались непрерывно - первый раз такое слышу. И какой же это диск нужно иметь? Перетирать данные как бы толк нулевой с такой частотой.

А это уже сложно. Неужели такая типичная и относительно простая по сути задача должна решаться столь сложными методами?
Сколько уже нашему Линуксу исполнилось лет? И что, до сих пор не предусмотрели нативного встроенного решения?

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

Потом 98% жрал мускул, но его прибивать нельзя, развалится база.

Если и БД постоянно грузит диск. Тут уже комплексный подход нужен. От оптимизации самого программного решения, EXPLAIN’ить запросы и смотреть почему так происходит, до распределения нагрузок по мощностям и выделения квот.

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

cgroup. Вроде Лёня сделал так, чтобы можно было одной строчкой в юните включить ограничения для сервиса.

И что, до сих пор не предусмотрели нативного встроенного решения?

Предусмотрели ­- systemd, параметры CPUWeight/CPUQuota, MemoryHigh/MemoryMax, IOWeight/IOReadBandwidthMax/IOWriteBandwidthMax, IOReadIOPSMax/IOWriteIOPSMax.

Для подробностей читайте man systemd.resource-control.

Бэкапы должны работать ежесекундно?

Да не бекапы, а мускул. Бекап я еще могу кильнуть, а базу опасно.

Из простого: man pv или диск нормальный.

Да какой еще уже диск! И так стоит черный WD на 4 ТБ.
Не диск надо менять, а оптимизировать выполнение задач.

И сдается мне, что в этой статье написана полная чушь -

Например, если у нас есть один процесс, работающий с приоритетом 10, а другой процесс работающий с приоритетом 15, то в первую очередь будет выполняться процесс приоритетом 10, а уже после него, тот, где приоритет 15.

Если верить написанному, то выходит, что если бекап будет длиться 5 часов, то все остальные задачи будут стоять??
Чушь собачья!

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

Включаю Вангу. Это вы за приоритетное планирование планировщика задач? Ну, правильно там все сказано. Задачи с высоким приоритетом выполняются первыми, с более низким - вторыми. Т.е. очень абстрагируя - за первый такт (естественно, не за такт, а для примера) отработают процессы у которых приоритет 10, за второй такт у которых 15 и т.д. Это если очень просто, там много факторов приоритизации, включая процессы «зомби», процессы занятые вводом-выводом и пр. Если глубоко копать в суть - я тоже здесь профан. Но по тексту цитаты (непонятно откуда) - там все верно написано.

Да не бекапы, а мускул. Бекап я еще могу кильнуть, а базу опасно.

Я по ОП так понял, что основной затык был в бэкапировании. Что там запускает остальное - непонятно. Наверняка тот же архиватор делает mysqldump или типа того. А может чего с оптимизацией самой базы или нагрузка на сайт критическая со вне идет. Как уже говорил:

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

cgroups

И что, до сих пор не предусмотрели нативного встроенного решения?

Насколько я понимаю, cgroups и есть нативное встроенное решение специально для руления такими вещами в Linux.

P.S. А, уже ответили :)

Может, и так, только сам термин «контейнеризация» мне совсем не понравился.
Насколько понял, что сервер, который работал 10 лет, надо переделывать?
Ну его, я лучше с найсами поиграюсь ;-)

В целом, для начала нужно прояснить, что вообще происходит на сервере. А ТС этого сам не знает. Например из этого:

Присмотрелся - один и процессов жрал аж 99%, и им оказался tar.
Понятно, что-то тарилось. Кильнул его.
Но тогда выполз exim, который жрал столько же, но килянию он не подавался.
Потом 98% жрал мускул, но его прибивать нельзя, развалится база.
Далее питон и прочая, прочая, прочая.

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

• ТС убивает tar - запускается архивация почты;
• убивает exim - отрабатывает mysqldump;
• и прочая, прочая, прочая.

Без понимания как отрабатывают процессы - ограничивать ресурсы непонятно каким именно образом. Без «разбора полетов» на самом сервере, ограничения ресурсов могут ухудшить ситуацию. Например, кривой скрипт на питоне, который дампит базу (вместо mysqldump). Может там гипервизор повыше стоит (ТС ничего об этом не писал), который лимитирует IO или банальные проблемы с дисковой системой, которые проявляются только под нагрузкой.

Вариантов масса. Нужна нормальная ревизия сервера. Потом можно решать, что делать дальше.

Нужна нормальная ревизия сервера.

Самое смешное, что сам же этот сервер и настраивал :-)
И скрипт для бекапирования тоже.
Но за многие годы система настолько обросла всякими нужными фишками, что уже и сам не вспомню, где, чего и как.

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

А перегруз диска объясняется просто - БД росла и достигла объема около 60 ГБ, и когда вместе встречаются бекап, мускул, почта и сфинкс - наступает полный абзац.

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

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

Для каких? Такое чувство, что не вам нужно, а нужно выпытывать -)

А перегруз диска объясняется просто - БД росла и достигла объема около 60 ГБ, и когда вместе встречаются бекап, мускул, почта и сфинкс - наступает полный абзац.

Ок. Если правильно понял - основная нагрузка при бэкапе БД идет, которым занимается самописный скрипт. Уже что-то.

1. Если при обычной работе сайта нет большой нагрузки (60 ГБ не прям сильно много на среднем сервере), все ок с индексами и запросами (реляционными связями) - на другую ноду (сервер/контейнер) её выносить не нужно. В обратном случае - нужно.

2. Сколько изменений происходит в БД в течении суток? Бэкапить все данные не нужно, тем более такой объем. Тот же mysqldump может и в отдельные таблицы, и в лимит записей, и в то и другое. Делаете основной бэкап, например, раз в месяц, а изменяемые данные ежедневно в формате dd_mm_yy.sql. Раз в месяц их архивируете и кладете к полному бэкапу БД.

В общем, переписывайте «скрипт для бекапирования».

Понятно, что-то тарилось. Кильнул его.

Но тогда выполз exim, который жрал столько же, но килянию он не подавался.

Забодало их килять, тем более что это почему-то ничего не давало.

Поэтому тупо перезагрузил сервак,

потом еще раз

Ахаха, что ты делаешь, прекрати)

Урок получил хороший

как понизить активность этих процессов

чтобы они меньше кушали

и человек, т.е. админ

Это один из тех постов, которые не прекращают доставлять

Нужна нормальная ревизия сервера.

Кстати, то, что тар кушает 99% io, это норма, так и должно быть)

Кстати, то, что тар кушает 99% io, это норма, так и должно быть)

Для него может быть и норма, но мне бы хотелось умерить его аппетит.
Архиваторы имеют такую возможность (выбор степени сжатия), а tar, увы, нет

Да. Только вряд ли он делает tar -cf archive.tar *. Это же бэкапы, по умолчанию сжимать нужно. Если tar, то tar -cvzf archive.tar.gz * обычно, а это совсем другая история.

Хз, так вроде для таких задач никто не делает, даже не задумывался. Ну, так-то да - первый вариант IO будет грузить сильно.

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

Архиваторы имеют такую возможность (выбор степени сжатия), а tar, увы, нет

Так опция, -z, например, указывает просто-напросто использовать gzip. По умолчанию у него степь сжатия 6 вроде.

Можно так, к примеру, сделать:

tar cvf - /home/chuckcha/* | gzip -9 -> archive.tar.gz

или

export GZIP=-9
tar cvzf archive.tar.gz /home/chuckcha/*

Все можно.

Тогда понято, почему у вас IO такой даже при tar. Но это и других причин не отменяет, с той же БД.

tar cvf - /home/chuckcha/* | gzip -9 -> archive.tar.gz

tar cvf - /home/chuckcha/* | gzip -9 > archive.tar.gz

Удачи вам всем в этом нелегком испытании :) Спать пойду. Понятно, что ничего не понято.

Да. Только вряд ли он делает tar -cf archive.tar *. Это же бэкапы, по умолчанию сжимать нужно

Нет, только тарю. И даже это занимает 4-5 часов.
А если еще и сжимать, то это даже не ночь займет, это будет длится вообще неизвестно сколько дней.

Для каких? Такое чувство, что не вам нужно, а нужно выпытывать -)

Уж извините, я не умею прогнозировать ваши вопросы ;-)

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

Нужна нормальная ревизия сервера.

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

И так стоит черный WD на 4 ТБ.

А перегруз диска объясняется просто - БД росла и достигла объема около 60 ГБ

60 гигабайт на одиночном hdd - это плохо и для сервера и для бэкапа.

Предусмотрели

Юзер-френдли, слов нет)

Понятно, что-то тарилось. Кильнул его.

И ты правда думаешь, что это нормальное решение?

Нет, только тарю. И даже это занимает 4-5 часов. А если еще и сжимать, то это даже не ночь займет, это будет длится вообще неизвестно сколько дней.

В твоем случае (99% IO), сжатие может значительно ускорить процесс, если у тебя не атом или целерон вместо процессора, если твои данные жмутся хотябы в 2-3 раза, то таким образом ты уменьшишь нагрузку на диск в соответствующее количество раз.

Admin walked into a bar

Видит, что-то тарится, кильнул.

Чисто анекдот.

до сих пор не предусмотрели нативного встроенного решения?

Здрасте-приехали, cgroup-ы и контейнеры в ядре уже черти сколько времени! Куда уж более нативно?

Нет, только тарю. И даже это занимает 4-5 часов.

Наоборот, время уменьшится. У вас же в диске «затык», если он захлебывается - сжатие снизит IO и ускорит процесс. Вообще, такое подозрение, что с самим диском что-то не то. Как будь-то он под нагрузкой греется и начинает тупить, как один из вариантов.

История, конечно, анекдотичная. Тред надо где-то закрепить :)

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

Я не вижу сервера о проблемах с которым ТС пишет.

База не помещается в оперативку (ну и что что она 60 Гб, добейте оперативки до 128 Гб или больше) что просто неприлично.

Затык по дисковым операциям - а один диск имеющийся в наличии никак не является дисковой подсистемой для нормального сервера. 8 (восемь) Х 12 Gb/s SAS SSD в RAID-60 с чего начинается самый простой сервер.

mysqldump умеет и без блокировки. Но в целом, все 60GB постоянно бекапить - подход неверный и бессмысленный.

8 (восемь) Х 12 Gb/s SAS SSD в RAID-60 с чего начинается самый простой сервер.

А вот и представители газпрома пожаловали.

В твоем случае (99% IO), сжатие может значительно ускорить процесс,

По многим причинам сумлеваюсь, конечно, но стоит попробовать.
А вдруг вы правы?

А вот и представители газпрома пожаловали.

anc Класс! Ваша юморная реплика мне очень понравилась, респект!

К остальным это тоже относится, которые чуть что, предлагают диск менять, оперативку в 6 раз увеличить и прочее.

Это мой личный сервер, и на такие апдейты у меня банально нет средств.
Головой думайте, а не апдейтами.

К остальным это тоже относится, которые чуть что, предлагают диск менять, оперативку в 6 раз увеличить и прочее.

Согласен. Ящитаю, нужно просто поменять админа.

Да я тоже с этого поржал) Нах нам бэкапы. Кильнуть все…..

Нах нам бэкапы. Кильнуть все…..

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

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

ТС пишет про случай в процессе разбора проблемы. Так что «смех-то гуевый».