Как гарантировать равное распределение ресурсов сервера между сайтами?
Всем доброго дня. Прошу помощи в поиске оптимального решения следующей задачи:
Имеется сервер (E3-1230v5/32gb/2Tb. Установлено: PHP/MySQL/Apache/Debian-8). На нём размещено десяток сайтов, у каждого сайта своя MySQL база данных (размером от 3-4gb), но используется один и тот же php код. На каждом сайте от 2 до 15 одновременных пользователей.
Обычно нагрузка на сервер приемлемая, и у всех всё работает быстро. Но, примерно раз в 3 дня на одном из сайтов запускаются очень ресурсоёмкие операции длительностью 10-15 минут. Тогда остальные копии сайтов просто ложатся.
Вопрос как обеспечить гарантированный ресурс сервера для всех? Пусть и ценой снижения общего быстродействия и увеличением времени сложных операций.
Сам думал над созданием десятка виртуальных серверов, но мне кажется, что держать десяток копий ОС и скриптов – как то не очень… Возможно, есть лучшее решение?
а зря так думаете про виртуалки, выделить каждой фиксированные ресурсы, тем самым перегрузка на одной не будет влиять на другие, если конечно же не будет перегрузки по нескольким сразу, заодно и изолируете физически друг от друга.
Вот и я, чем больше про них думаю, тем больше нравится эта идея. Но на сколько возрастут накладные расходы при таком подходе? Ну и, возможно глупый вопрос, нужно ли будет для каждой виртуальной машины делать свой внешний IP адрес?
Почему, же не устраивают? просто я не совсем вкурсе серверных технологий, потому и задал вопрос о вариантах решения. Чтобы знать про что читать. Вам спасибо за ответ.
В современных ОС приоритеты и квоты ресурсов можно задавать и без контейнеров и других способов виртуализации (эти технологии как раз на этих возможностях ОС и основаны). Только это муторно и тяжело поддерживать. Я бы обратил внимание на контейнеры LXC. Сам использую их в Proxmox.
mamayama: Вы опять путаете нагрузку по каличеству запросов и 1 запрос на на серьёзную обработку данных.
Скажем на построение полного графа аналогов какой либо запчасти от всех, известных системе, поизводителей и поставщиков. Чтобы было понятно: 740 миллинов наименований запчастей, 4000 поставщиков, есть список оффициальных и неоффициальных (по конкретному поставщику) замен, каждая запчасть может быть связана с другими через 5-6 промежуточных звеньев. Общее количество аналогов в 1 графе - от 3 до 500.
Для решения подобной задачи, нужно много времени, но не очень много ресурсов. Однако на время её выполнения замедлится работа всей системы.
SorokinWS:
А я то думал что там какая-то сложная обработка....
Это простая задача, полагаю, что на вашем железе вполне можно добиться производительности обработки запросов порядка 5 000-30 000 в секунду.
Простите, но я опять таки обращу внимание, что это делал хреновый программист.
Графовые данные весьма плохо ложатся на концепцию реляционных СУБД.
Не нужно было её выбирать, если уж задача именно такова как вы описываете и вызывает проблемы с производительностью
По вашей задаче ответ можно отдавать пользователю практически мгновенно (с точки зрения человека, он не заметит задержки больше, нежели задержка передачи информации по сети интернет).
Для решения подобной задачи, нужно много времени, но не очень много ресурсов.
Насчет времени не соглашусь, времени там нужно доли секунды на каждый поиск (в т. ч. и с учетом графа).
Насчет ресурсов не согласен - эта задача просто ракетно ускоряется путем размещения данных в оперативной памяти, то есть чего чего, а оперативку может кушать интенсивно.
Но нагрузка на процессор - согласен - для вашего количества запросов должна быть незначительная.
Так что непонятно от чего ваши процессы мешают друг другу.
Вы можете заставить программиста довести систему до ума?
Если нет (программист уволился к примеру), то, да - проще просто добавить железа и прописать приоритеты процессам.
SorokinWS:
в замерах на hello world основные затраты - это запуск, старт, МИЗЕРНОЕ ВРЕМЯ собственно полезной работы, затем отдача ответа.
в вашей задаче - основные затраты это не запуск и ответ, а работа с БД, поиск, перебор. ни какой связи с hello world это не имеет.
SorokinWS:
2 Г * 10 клиентов = 20 Г при наличии памяти в 32 Г на сервер, выделенном, как я понимаю, только под эту задачу - неужели является проблемой?
если вы экономите память под будущее расширение, то достаточно размещать в оперативной памяти только индексные данные.
плюс, насколько я понимаю, речь идет о каталоге запчастей - значительная часть запчастей идентична. что также позволяет сэкономить, размещая данные в оперативке в одном экземпляре
P.S.:
но на самом деле экономить в данном конкретном случае, и не нужно, ибо
В любом случае при постраении графа из реляционной базы данных требуется ЛИБО извлекать сразу большое количество данных и их обрабатывать ЛИБО делать большое количество запросов. Первый вариант - быстрый но затратный по ресурсам, второй - наоборот.
Эта система кроме того, ведёт складской учёт, продажи, закупки, подсчёт статистики и генерация отчётности (временами довольно замысловатой). В работе используется почти всё, что есть в базе. (средней размер базы данных 75gb). Запихивать всё это в память - нереально.
значительная часть запчастей идентична - нет. они взаимозаменяемы но не одинаковы.
В любом случае при постраении графа из реляционной базы данных требуется ЛИБО извлекать сразу большое количество данных и их обрабатывать ЛИБО делать большое количество запросов. Первый вариант - быстрый но затратный по ресурсам, второй - наоборот.
Эта система кроме того, ведёт складской учёт, продажи, закупки, подсчёт статистики и генерация отчётности (временами довольно замысловатой). В работе используется почти всё, что есть в базе. (средней размер базы данных 75gb). Запихивать всё это в память - нереально.
Я полагаю, что наибольшая сложность здесь в том, что речь идет уже о какой то существующей системы, которую уже не хочется (не можется) переделывать.
Но, абстрагируясь от неё, на вашей задаче вполне можно отдавать ответ мгновенно (время передачи по сети будет больше, чем поиск в БД).
mamayama: Вы же в курсе, что у них не единственный сервер? про кеширование, наверное, тоже знаете? И наверняка знаете чем, в плане политики кеширования, отличается CRM и социальная сеть?
К тому же в facebook не случайно разработали HHVM.
mamayama:
Разумеется один сервер держит несколько тысяч пользователей, но это результат кеширования.
Данные в системе постоянно меняются, то, что возможно - уже закешировано. Остальное требует максимально возможной актуальности данных.
Что значит "вы отдаете клиенту данные из большого каталога непосредственно из CRM" - В CRM работают сотрудники, клиенты не имеют доступа ни к каталогу, ни к системе. Данные поставщиков и магазинов приходят чере REST интерфейсы. Связь с внешними системами тоже через API.
Разумеется один сервер держит несколько тысяч пользователей, но это результат кеширования.
Миллионы, а не тысячи - и это результат кэширование.
Поэтому я и утверждаю - ваша нагрузка это ничто.
Дело в плохо спроектированной системе.
Ну или в использовании плохо подходящей под задачу системе.
Данные в системе постоянно меняются, то, что возможно - уже закешировано. Остальное требует максимально возможной актуальности данных.
Речь не идет о классическом кэше, который берет данные из БД на диске только при промахах.
Количество записей в БД на фоне количества чтений из кэша настолько мизерно, насколько я понимаю вашу задачу, что целесообразно сразу обновлять кэш, который по факту будет являться в данном случае вторичной БД, заточенной на ответы на запросы.
Эта система кроме того, ведёт складской учёт, продажи, закупки, подсчёт статистики и генерация отчётности (временами довольно замысловатой). В работе используется почти всё, что есть в базе. (средней размер базы данных 75gb). Запихивать всё это в память - нереально.
А и не надо всю базу.
Сотрудники навряд ли генерируют такой большой поток изменений, как запросы с внешнего мира.
Вполне достаточно каталог.
После чего у вас останется еще куча оперативки под остальные задачи, кроме каталога.
Что значит "вы отдаете клиенту данные из большого каталога непосредственно из CRM" - В CRM работают сотрудники, клиенты не имеют доступа ни к каталогу, ни к системе. Данные поставщиков и магазинов приходят чере REST интерфейсы. Связь с внешними системами тоже через API.
Речь о БД.
Отдаете из БД CRM, которая, по логичным причинам, не оптимизирована для отдачи данных на большое число запросов.
А оптимизировано под гибкость.
Затачивает отдельную систему под отдачу запросов, используя агрессивное кэширование (пожалуй даже всего) каталога в виде вторичной БД для каталога - и отдаем ответы на запросы посетителей сайта за доли секунды.
Другое дело, что это может быть не целесообразно по экономическим причинам.
Программисту уже уплачено и он ушел заниматься другими системами.
Но изначально, если бы стояла задача обслуживать большое число клиентов на сайтах - стоило бы сделать именно так.
Более того - каталог вполне можно было держать и в одном экземпляре только в оперативной памяти, а не дублировать БД с диска. И использовать её и для обращения к каталогу собственных сотрудников.
Скажем СУБД Tarantool это позволяет осуществлять без потери данных в случае перезагрузки сервера. Все изменения оперативно сохраняются на диске.
Средний
