Обеспечение реактивности системы.
От: WolfHound  
Дата: 03.10.07 10:53
Оценка:
Есть некий демон обрабатывающий очень тяжолые запросы.
Эти запросы очень любят CPU и память. IO минимально.
Из-за чего они выполняются в пуле потоков с очень маленьким колличеством потоков. (Обычно колличество CPU-1)
Обычно эти запросы отрабатывают за 1-5 секунд.
Однако есть некоторое колличетво клинических запросов которые обрабатываются сотни секунд.
Обычно таких запросов сильно меньше чем потоков в пуле.
Но иногда их становится больше... и в этом случае тормозят все.
Засада в том что пока не начнешь обрабатывать запрос определить сколько он будет работать нельзя.

Задача сделать так чтобы при наплыве клинических запросов относительно быстрые запросы продолжали отрабатывать быстро, а не висели в очереди на исполнение.

Пока ничего умнее чем пристрелить клинический запрос и направить его в отдельный пул для клинических случаев в голову не приходит.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re: Обеспечение реактивности системы.
От: kaa.python Ниоткуда РСДН профессионально мёртв и завален ватой.
Дата: 03.10.07 11:01
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Пока ничего умнее чем пристрелить клинический запрос и направить его в отдельный пул для клинических случаев в голову не приходит.


Можно попробовать добавить менеджер, который отслеживает время выполнения потока. В случае если время выполнения определенного потока превосходит некий лимит, потоку понижается приоритет, соответственно нагрузка на процессор падает.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[2]: Обеспечение реактивности системы.
От: kaa.python Ниоткуда РСДН профессионально мёртв и завален ватой.
Дата: 03.10.07 11:07
Оценка: 2 (2)
Здравствуйте, kaa.python, Вы писали:

KP>Можно попробовать добавить менеджер, который отслеживает время выполнения потока. В случае если время выполнения определенного потока превосходит некий лимит, потоку понижается приоритет, соответственно нагрузка на процессор падает.


Еще подумал. Может есть возможность добавить в функцию вычисления некую контрольную точку, в которой уже можно определить, что вычисления тяжеловесные? Соответственно в данной точке делать блокировку потока по семофору, к примеру когда количество тяжелых процессов становится больше 3-х.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[2]: Обеспечение реактивности системы.
От: WolfHound  
Дата: 03.10.07 11:14
Оценка:
Здравствуйте, kaa.python, Вы писали:

KP>Можно попробовать добавить менеджер, который отслеживает время выполнения потока. В случае если время выполнения определенного потока превосходит некий лимит, потоку понижается приоритет, соответственно нагрузка на процессор падает.

Безполезно.
Колличество потоков в пуле ограничено.
И поднять это колличество нельзя ибо там отжирается не только процессор но и память.
Перейти на 64 бита нельзя ибо там есть либы которые под 64 бита не работают.
Да и проблему это не решает, а только не сильно увеличивает колличество клинических запросов которое душит систему.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[3]: Обеспечение реактивности системы.
От: Flamer Кипр http://users.livejournal.com/_flamer_/
Дата: 03.10.07 11:30
Оценка:
Здравствуйте, WolfHound, Вы писали:

[]

WH>Колличество потоков в пуле ограничено.

WH>И поднять это колличество нельзя ибо там отжирается не только процессор но и память.

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

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

Надо математически обосновывать, в общем. Но мысль ясна, я думаю.
... << RSDN@Home 1.1.4 beta 7 rev. 452>>
Re: Обеспечение реактивности системы.
От: IT Россия linq2db.com
Дата: 03.10.07 11:31
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Засада в том что пока не начнешь обрабатывать запрос определить сколько он будет работать нельзя.


Разбить обратотку на до и после определения нельзя?
Неясность изложения обычно происходит от путаницы в мыслях.
//rsdn.org/forum/images/bis.gif Если нам не помогут, то мы тоже никого не пощадим.
Re[4]: Обеспечение реактивности системы.
От: WolfHound  
Дата: 03.10.07 11:37
Оценка: +1
Здравствуйте, Flamer, Вы писали:

F>Тогда может имеет смысл сделать один слот в пуле резервным? Я так мыслю, что ситуация, когда критические запросы занимают весь пул — вырожденная а потому клиническая. В случае, если такая ситуация возникает — пихаем новый запрос в резервный слот.

ИМХО это ничем не отлячается от увеличения колличества потоков в пуле на 1.
Ибо в этот слот обязательно попадет клинический запрос.

F>Надо математически обосновывать, в общем. Но мысль ясна, я думаю.

Ясна. Но ИМХО мимо.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[2]: Обеспечение реактивности системы.
От: WolfHound  
Дата: 03.10.07 11:45
Оценка:
Здравствуйте, IT, Вы писали:

IT>Разбить обратотку на до и после определения нельзя?

Нельзя.
Можно только по ходу обработки понять что обработка вероятно будет долгой.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[3]: Обеспечение реактивности системы.
От: akasoft Россия  
Дата: 03.10.07 15:08
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Можно только по ходу обработки понять что обработка вероятно будет долгой.


И приостановить, поставить в очередь, но уже с флагом "тормоза!" и пр. нельзя?

Уж не ядерным ли реактором управляешь?

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

WH>Пока ничего умнее чем пристрелить клинический запрос и направить его в отдельный пул для клинических случаев в голову не приходит.


Ага, значит таки можно перенаправить запрос.
... << RSDN@Home 1.2.0 alpha rev. 717>> SQL Express 2005
Re[4]: Обеспечение реактивности системы.
От: WolfHound  
Дата: 03.10.07 17:17
Оценка: 1 (1)
Здравствуйте, akasoft, Вы писали:

A>И приостановить, поставить в очередь, но уже с флагом "тормоза!" и пр. нельзя?

Обработка жрет много памяти.

A>Уж не ядерным ли реактором управляешь?

Это ты к чему?

A>М.б. можно в некой пре-обработке выявить по каким-либо признакам, что запрос "возможно клинический", и перевести его в отдельную очередь? Или наоборот, выявлять потенциально быстрые, и таким образом их развести.

Написание и эффективность такой предобработки сравнима с самой обработкой.
Так что мне проще пропатчить обработку чтобы она в клинических случаях обламывалась и говорила запросившему демону чтобы спросил еще раз но в соседнем пуле потоков.

A>Ага, значит таки можно перенаправить запрос.

Запрос это некий пакет данных который обрабатывается.
Соответственно его обработку можно на пол пути прибить и начать заново.
Но обрабатывать нужно по возможности в реальном времени ибо пользователи ждут ответ.
А те кто задали клинический запрос пусть ждут но при этом не мешают другим.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re: Обеспечение реактивности системы.
От: Стэн http://stanonwork.blogspot.com/
Дата: 03.10.07 17:30
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Засада в том что пока не начнешь обрабатывать запрос определить сколько он будет работать нельзя.

А в чем состоит обработка запросов? Иначе мне представляется очень сомнительным, что эту задачу можно решить как черный ящик?
В общем случае можно справиться с нагрузкой на процессор, если реализовать некоторое подобие кооперативной многозадачности — через определенные промежутки времени каждый обработчик останавливается и отдает управление некоторому менеджеру, который решает что делать дальше — продолжать обработку данного запроса или приостановить обработку и взять новый запрос.
Только непонятно как быть с памятью. Можно ли у обработчика, пока он отдыхает, отобрать ее для новых запросов?
Re[2]: Обеспечение реактивности системы.
От: Константин Л. Франция  
Дата: 03.10.07 17:59
Оценка:
Здравствуйте, Стэн, Вы писали:

С>Здравствуйте, WolfHound, Вы писали:


WH>>Засада в том что пока не начнешь обрабатывать запрос определить сколько он будет работать нельзя.

С>А в чем состоит обработка запросов? Иначе мне представляется очень сомнительным, что эту задачу можно решить как черный ящик?
С>В общем случае можно справиться с нагрузкой на процессор, если реализовать некоторое подобие кооперативной многозадачности — через определенные промежутки времени каждый обработчик останавливается и отдает управление некоторому менеджеру, который решает что делать дальше — продолжать обработку данного запроса или приостановить обработку и взять новый запрос.

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

С>Только непонятно как быть с памятью. Можно ли у обработчика, пока он отдыхает, отобрать ее для новых запросов?
Re[5]: Обеспечение реактивности системы.
От: Константин Л. Франция  
Дата: 03.10.07 18:01
Оценка:
Здравствуйте, WolfHound, Вы писали:

[]

A>>М.б. можно в некой пре-обработке выявить по каким-либо признакам, что запрос "возможно клинический", и перевести его в отдельную очередь? Или наоборот, выявлять потенциально быстрые, и таким образом их развести.

WH>Написание и эффективность такой предобработки сравнима с самой обработкой.
WH>Так что мне проще пропатчить обработку чтобы она в клинических случаях обламывалась и говорила запросившему демону чтобы спросил еще раз но в соседнем пуле потоков.

А пулов несколько? А кто определяет, в какой пул класть? Так может пусть демон спрашивает, в какой лучше пул положить запрос?

[]
Re[3]: Обеспечение реактивности системы.
От: Стэн http://stanonwork.blogspot.com/
Дата: 03.10.07 18:25
Оценка:
Здравствуйте, Константин Л., Вы писали:

КЛ>дык за нас это умеет виндовый шедулер, а включается это приоритетами.

Судя по терминологии (демоны), речь идет о Unix-системах, но очевидно, что и там есть планировщик...
Только приоритетами это не решается, так как основная проблема не в том, чтобы хоть один выполнялся быстро, а в том, чтобы не забить огрниченное кол-во потоков тяжелыми запросами.
Re[5]: Обеспечение реактивности системы.
От: akasoft Россия  
Дата: 03.10.07 18:26
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Это ты к чему?


К категоричности заявления, что нельзя разбить обработку. Ну, нельзя и нельзя. Тут только можно с умным видом посетовать на "кривой дизайн".

WH>Написание и эффективность такой предобработки сравнима с самой обработкой.


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

Классический способ, по моему, бы выглядел так: клиент — планировщик — демон. Клиент формирует запрос и посылает планировщику. Тот анализирует, и рассовывает в очереди на обработку. Пусть их две: для простых запросов и для клинических. Демон выбирает и обрабатывает. Такое вот разделение труда.
... << RSDN@Home 1.2.0 alpha rev. 717>> SQL Express 2005
Re[6]: Обеспечение реактивности системы.
От: WolfHound  
Дата: 03.10.07 19:49
Оценка:
Здравствуйте, Константин Л., Вы писали:

КЛ>А пулов несколько? А кто определяет, в какой пул класть? Так может пусть демон спрашивает, в какой лучше пул положить запрос?

Дык эта... пока не начнешь обрабатывать степень клиничности запроса не определить.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[6]: Обеспечение реактивности системы.
От: WolfHound  
Дата: 03.10.07 19:49
Оценка:
Здравствуйте, akasoft, Вы писали:

A>Классический способ, по моему, бы выглядел так: клиент — планировщик — демон. Клиент формирует запрос и посылает планировщику.

A>Тот анализирует, и рассовывает в очереди на обработку.
Анализ по времени и сложности будет равен обработке...
A>Пусть их две: для простых запросов и для клинических. Демон выбирает и обрабатывает. Такое вот разделение труда.
См последнею строчку первого поста...
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re: Обеспечение реактивности системы.
От: UrryMcA Россия http://www.UrryMcA.com
Дата: 04.10.07 07:11
Оценка:
Здравствуйте, WolfHound, Вы писали:

Разделить непосредственно обработчик и обрабатываемый объект.
При появлении соответствующих показаний передать объект обработчику с более низким приоритетом.
Re: Обеспечение реактивности системы.
От: frogkiller Россия  
Дата: 04.10.07 08:25
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Пока ничего умнее чем пристрелить клинический запрос и направить его в отдельный пул для клинических случаев в голову не приходит.


Раз уж всё равно создаёшь второй пул, зачем пристреливать текущий запрос? Не достаточно ли будет сделать один динамический пул с фиксированной нижней границей? Или, если нельзя изменять статический пул, — создавать второй динамический, и направлять туда все запросы при полной загрузке статического. Всё равно полностью от накладных расходов в этой ситуации избавиться не удастся.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Курица — это инструмент, с помощью которого одно яйцо производит другие.
Re: Обеспечение реактивности системы.
От: DerBober США  
Дата: 04.10.07 08:55
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Задача сделать так чтобы при наплыве клинических запросов относительно быстрые запросы продолжали отрабатывать быстро, а не висели в очереди на исполнение.


Демон является частью распределенной системы ему подобных? Запросы можно балансировать между машинами?
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.