Есть некий демон обрабатывающий очень тяжолые запросы.
Эти запросы очень любят CPU и память. IO минимально.
Из-за чего они выполняются в пуле потоков с очень маленьким колличеством потоков. (Обычно колличество CPU-1)
Обычно эти запросы отрабатывают за 1-5 секунд.
Однако есть некоторое колличетво клинических запросов которые обрабатываются сотни секунд.
Обычно таких запросов сильно меньше чем потоков в пуле.
Но иногда их становится больше... и в этом случае тормозят все.
Засада в том что пока не начнешь обрабатывать запрос определить сколько он будет работать нельзя.
Задача сделать так чтобы при наплыве клинических запросов относительно быстрые запросы продолжали отрабатывать быстро, а не висели в очереди на исполнение.
Пока ничего умнее чем пристрелить клинический запрос и направить его в отдельный пул для клинических случаев в голову не приходит.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Пока ничего умнее чем пристрелить клинический запрос и направить его в отдельный пул для клинических случаев в голову не приходит.
Можно попробовать добавить менеджер, который отслеживает время выполнения потока. В случае если время выполнения определенного потока превосходит некий лимит, потоку понижается приоритет, соответственно нагрузка на процессор падает.
Здравствуйте, kaa.python, Вы писали:
KP>Можно попробовать добавить менеджер, который отслеживает время выполнения потока. В случае если время выполнения определенного потока превосходит некий лимит, потоку понижается приоритет, соответственно нагрузка на процессор падает.
Еще подумал. Может есть возможность добавить в функцию вычисления некую контрольную точку, в которой уже можно определить, что вычисления тяжеловесные? Соответственно в данной точке делать блокировку потока по семофору, к примеру когда количество тяжелых процессов становится больше 3-х.
Здравствуйте, kaa.python, Вы писали:
KP>Можно попробовать добавить менеджер, который отслеживает время выполнения потока. В случае если время выполнения определенного потока превосходит некий лимит, потоку понижается приоритет, соответственно нагрузка на процессор падает.
Безполезно.
Колличество потоков в пуле ограничено.
И поднять это колличество нельзя ибо там отжирается не только процессор но и память.
Перейти на 64 бита нельзя ибо там есть либы которые под 64 бита не работают.
Да и проблему это не решает, а только не сильно увеличивает колличество клинических запросов которое душит систему.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
[]
WH>Колличество потоков в пуле ограничено. WH>И поднять это колличество нельзя ибо там отжирается не только процессор но и память.
Тогда может имеет смысл сделать один слот в пуле резервным? Я так мыслю, что ситуация, когда критические запросы занимают весь пул — вырожденная а потому клиническая. В случае, если такая ситуация возникает — пихаем новый запрос в резервный слот.
Конечно, это не решение, однако теоретически может сильно помочь уменьшить тормоза. Конечно, лишь в том случае, если кол-во быстрых запросов превосходит кол-во тяжелых на какую-то критичную величину. Т.е. в случае решения с резервным слотом все сводится к тому, что по теории вероятности, если все остальные слоты заняты, туда с большей вероятностью попадет легкий запрос.
Надо математически обосновывать, в общем. Но мысль ясна, я думаю.
Здравствуйте, Flamer, Вы писали:
F>Тогда может имеет смысл сделать один слот в пуле резервным? Я так мыслю, что ситуация, когда критические запросы занимают весь пул — вырожденная а потому клиническая. В случае, если такая ситуация возникает — пихаем новый запрос в резервный слот.
ИМХО это ничем не отлячается от увеличения колличества потоков в пуле на 1.
Ибо в этот слот обязательно попадет клинический запрос.
F>Надо математически обосновывать, в общем. Но мысль ясна, я думаю.
Ясна. Но ИМХО мимо.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, IT, Вы писали:
IT>Разбить обратотку на до и после определения нельзя?
Нельзя.
Можно только по ходу обработки понять что обработка вероятно будет долгой.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Можно только по ходу обработки понять что обработка вероятно будет долгой.
И приостановить, поставить в очередь, но уже с флагом "тормоза!" и пр. нельзя?
Уж не ядерным ли реактором управляешь?
М.б. можно в некой пре-обработке выявить по каким-либо признакам, что запрос "возможно клинический", и перевести его в отдельную очередь? Или наоборот, выявлять потенциально быстрые, и таким образом их развести.
WH>Пока ничего умнее чем пристрелить клинический запрос и направить его в отдельный пул для клинических случаев в голову не приходит.
Здравствуйте, akasoft, Вы писали:
A>И приостановить, поставить в очередь, но уже с флагом "тормоза!" и пр. нельзя?
Обработка жрет много памяти.
A>Уж не ядерным ли реактором управляешь?
Это ты к чему?
A>М.б. можно в некой пре-обработке выявить по каким-либо признакам, что запрос "возможно клинический", и перевести его в отдельную очередь? Или наоборот, выявлять потенциально быстрые, и таким образом их развести.
Написание и эффективность такой предобработки сравнима с самой обработкой.
Так что мне проще пропатчить обработку чтобы она в клинических случаях обламывалась и говорила запросившему демону чтобы спросил еще раз но в соседнем пуле потоков.
A>Ага, значит таки можно перенаправить запрос.
Запрос это некий пакет данных который обрабатывается.
Соответственно его обработку можно на пол пути прибить и начать заново.
Но обрабатывать нужно по возможности в реальном времени ибо пользователи ждут ответ.
А те кто задали клинический запрос пусть ждут но при этом не мешают другим.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Засада в том что пока не начнешь обрабатывать запрос определить сколько он будет работать нельзя.
А в чем состоит обработка запросов? Иначе мне представляется очень сомнительным, что эту задачу можно решить как черный ящик?
В общем случае можно справиться с нагрузкой на процессор, если реализовать некоторое подобие кооперативной многозадачности — через определенные промежутки времени каждый обработчик останавливается и отдает управление некоторому менеджеру, который решает что делать дальше — продолжать обработку данного запроса или приостановить обработку и взять новый запрос.
Только непонятно как быть с памятью. Можно ли у обработчика, пока он отдыхает, отобрать ее для новых запросов?
Здравствуйте, Стэн, Вы писали:
С>Здравствуйте, WolfHound, Вы писали:
WH>>Засада в том что пока не начнешь обрабатывать запрос определить сколько он будет работать нельзя. С>А в чем состоит обработка запросов? Иначе мне представляется очень сомнительным, что эту задачу можно решить как черный ящик? С>В общем случае можно справиться с нагрузкой на процессор, если реализовать некоторое подобие кооперативной многозадачности — через определенные промежутки времени каждый обработчик останавливается и отдает управление некоторому менеджеру, который решает что делать дальше — продолжать обработку данного запроса или приостановить обработку и взять новый запрос.
дык за нас это умеет виндовый шедулер, а включается это приоритетами.
С>Только непонятно как быть с памятью. Можно ли у обработчика, пока он отдыхает, отобрать ее для новых запросов?
[]
A>>М.б. можно в некой пре-обработке выявить по каким-либо признакам, что запрос "возможно клинический", и перевести его в отдельную очередь? Или наоборот, выявлять потенциально быстрые, и таким образом их развести. WH>Написание и эффективность такой предобработки сравнима с самой обработкой. WH>Так что мне проще пропатчить обработку чтобы она в клинических случаях обламывалась и говорила запросившему демону чтобы спросил еще раз но в соседнем пуле потоков.
А пулов несколько? А кто определяет, в какой пул класть? Так может пусть демон спрашивает, в какой лучше пул положить запрос?
Здравствуйте, Константин Л., Вы писали:
КЛ>дык за нас это умеет виндовый шедулер, а включается это приоритетами.
Судя по терминологии (демоны), речь идет о Unix-системах, но очевидно, что и там есть планировщик...
Только приоритетами это не решается, так как основная проблема не в том, чтобы хоть один выполнялся быстро, а в том, чтобы не забить огрниченное кол-во потоков тяжелыми запросами.
Здравствуйте, WolfHound, Вы писали:
WH>Это ты к чему?
К категоричности заявления, что нельзя разбить обработку. Ну, нельзя и нельзя. Тут только можно с умным видом посетовать на "кривой дизайн".
WH>Написание и эффективность такой предобработки сравнима с самой обработкой.
Раз нельзя ни выделить отдельно предобработку, ни написать заново, остаётся только обламывать запрос. Далее зависит от реакции клиентского ПО на код облома. М.б. можно в этом случае передавать признак того, что облом был, и реагировать соответствено. Ну либо демон сам обламывает запрос, и ставит этот "пакет данных" в очередь опять, но с признаком, чтобы выделить этот запрос от других. Либо в иную очередь. В зависимости от ситуации, научить либо клиентов, либо демон наличию этой второй очереди.
Классический способ, по моему, бы выглядел так: клиент — планировщик — демон. Клиент формирует запрос и посылает планировщику. Тот анализирует, и рассовывает в очереди на обработку. Пусть их две: для простых запросов и для клинических. Демон выбирает и обрабатывает. Такое вот разделение труда.
Здравствуйте, Константин Л., Вы писали:
КЛ>А пулов несколько? А кто определяет, в какой пул класть? Так может пусть демон спрашивает, в какой лучше пул положить запрос?
Дык эта... пока не начнешь обрабатывать степень клиничности запроса не определить.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, akasoft, Вы писали:
A>Классический способ, по моему, бы выглядел так: клиент — планировщик — демон. Клиент формирует запрос и посылает планировщику. A>Тот анализирует, и рассовывает в очереди на обработку.
Анализ по времени и сложности будет равен обработке... A>Пусть их две: для простых запросов и для клинических. Демон выбирает и обрабатывает. Такое вот разделение труда.
См последнею строчку первого поста...
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Разделить непосредственно обработчик и обрабатываемый объект.
При появлении соответствующих показаний передать объект обработчику с более низким приоритетом.
Здравствуйте, WolfHound, Вы писали:
WH>Пока ничего умнее чем пристрелить клинический запрос и направить его в отдельный пул для клинических случаев в голову не приходит.
Раз уж всё равно создаёшь второй пул, зачем пристреливать текущий запрос? Не достаточно ли будет сделать один динамический пул с фиксированной нижней границей? Или, если нельзя изменять статический пул, — создавать второй динамический, и направлять туда все запросы при полной загрузке статического. Всё равно полностью от накладных расходов в этой ситуации избавиться не удастся.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Курица — это инструмент, с помощью которого одно яйцо производит другие.
Здравствуйте, WolfHound, Вы писали:
WH>Задача сделать так чтобы при наплыве клинических запросов относительно быстрые запросы продолжали отрабатывать быстро, а не висели в очереди на исполнение.
Демон является частью распределенной системы ему подобных? Запросы можно балансировать между машинами?
Если нам не помогут, то мы тоже никого не пощадим.
