Обеспечение реактивности системы.
От: 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>Засада в том что пока не начнешь обрабатывать запрос определить сколько он будет работать нельзя.


Разбить обратотку на до и после определения нельзя?
Неясность изложения обычно происходит от путаницы в мыслях.
Если нам не помогут, то мы тоже никого не пощадим.
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>Задача сделать так чтобы при наплыве клинических запросов относительно быстрые запросы продолжали отрабатывать быстро, а не висели в очереди на исполнение.


Демон является частью распределенной системы ему подобных? Запросы можно балансировать между машинами?
Re: Обеспечение реактивности системы.
От: MaximVK Россия  
Дата: 04.10.07 09:37
Оценка: 1 (1) +3
Здравствуйте, WolfHound, Вы писали:

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


Судя по постановке задачи ничего умнее тут ты и не придумаешь. Тут вопрос только как правильно реализовать эту стратегию. По уму, нужно четко сформулировать критерий который нужно максимизировать и потом уже выбирать стратегию его максимизации(я так понимаю, это реактивность системы). Потом нужно собрать статистику по пакетам и построить два распределения:
1. Распределение пакетов по времени выполнения.
2. Распределение временных промежутков между пакетами.

Потом построить мат. модель и выстраивать стратегию. Параметрами стратегии могут быть, например:
1. Время выполнения пакета, после прохождения которого считать пакет клиническим.
2. Сколько клинических пакетов может выполняться одновременно.
3. Критерий выбора клинического пакета на уничтожение.
4. ...

Но начинать надо с формулировки реактивности системы в количественных показателях.

P.S. Еще можно погуглить на тему теории массового обслуживания.
Re[7]: Обеспечение реактивности системы.
От: Константин Л. Франция  
Дата: 04.10.07 09:50
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Константин Л., Вы писали:


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

WH>Дык эта... пока не начнешь обрабатывать степень клиничности запроса не определить.

ну так заведи шареный флажок, который будет показывать кол-во критичных тасков в этом пуле. По нему определяй, в какой пул класть
Re[2]: Обеспечение реактивности системы.
От: WolfHound  
Дата: 04.10.07 10:54
Оценка:
Здравствуйте, UrryMcA, Вы писали:

UMA>Разделить непосредственно обработчик и обрабатываемый объект.

UMA>При появлении соответствующих показаний передать объект обработчику с более низким приоритетом.
Память.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[2]: Обеспечение реактивности системы.
От: WolfHound  
Дата: 04.10.07 10:54
Оценка:
Здравствуйте, frogkiller, Вы писали:

F>Раз уж всё равно создаёшь второй пул, зачем пристреливать текущий запрос? Не достаточно ли будет сделать один динамический пул с фиксированной нижней границей? Или, если нельзя изменять статический пул, — создавать второй динамический, и направлять туда все запросы при полной загрузке статического. Всё равно полностью от накладных расходов в этой ситуации избавиться не удастся.

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

DB>Демон является частью распределенной системы ему подобных?

Да.
DB>Запросы можно балансировать между машинами?
Можно. И уже давно сделано.
Но всеравно при наплыве клинических запросов забиваются все пулы.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[2]: Обеспечение реактивности системы.
От: WolfHound  
Дата: 04.10.07 10:54
Оценка:
Здравствуйте, MaximVK, Вы писали:

MVK>Потом нужно собрать статистику по пакетам и построить два распределения:

MVK>1. Распределение пакетов по времени выполнения.
MVK>2. Распределение временных промежутков между пакетами.
А толку?
Обычно клинические запросы приходят несколько раз в день и никого не напрягают.
При том что всего запросов десятки тысяч.
Проблема с аномальными наплывыми клинических запросов.
Это когда в течении десятков минут приходят сотни клинических запросов.
Пока такое было всего один раз но осадок остался.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[2]: Обеспечение реактивности системы.
От: MaximVK Россия  
Дата: 04.10.07 11:10
Оценка: +3
Здравствуйте, MaximVK, Вы писали:

MVK>P.S. Еще можно погуглить на тему теории массового обслуживания.


Добавлю еще пять копеек. Похожие задачи возникают при оценке нагрузки на телефонный узел. Если перевести твою задачу в телефонные термины, то количество потоков — это количество телефонных линий, пакет — это телефонный звонок, а время обработки пакета — это длительность телефонного разговора. Правда, там обычно решается несколько другая задача(хотя я и не удивлюсь, если решалась и твоя): какое количество линий нужно, чтобы при заданных условиях обеспечить приемлемую работу узла? Под заданными условиями обычно подразумеваются приведенные мной распределения, а под приемлемой работой вероятность отказа абоненту в обслуживании. Возможно, не обязательно нужно строить мат. модель, а оптимальную стратегию можно получить через моделирование.
Re[3]: Обеспечение реактивности системы.
От: DerBober США  
Дата: 04.10.07 11:28
Оценка:
Здравствуйте, WolfHound, Вы писали:

DB>>Демон является частью распределенной системы ему подобных?

WH>Да.
DB>>Запросы можно балансировать между машинами?
WH>Можно. И уже давно сделано.
WH>Но всеравно при наплыве клинических запросов забиваются все пулы.

Можно ли перетащить выполняющийся запрос на другую машину? Например остановить вычисления и запустить на другой машине сначала. Результат от этого изменится?

Если перетащить запрос можно, тогда можно снимать с выполнения клинические запросы (выполняющиеся более N (5-и) сек) и распределять либо во времени (ждать пока в системе таких запросов станет менее K (10-х) штук и после запускать заново) или в пространстве (раскидывать их на спец. машины для клинических запросов). Только параметры надо аккуратно подобрать т.е. моделировать систему придется.
Re: Обеспечение реактивности системы.
От: ivb22  
Дата: 04.10.07 18:38
Оценка: 1 (1) +1
Здравствуйте, WolfHound, Вы писали:

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


Отдельный пул — это новые треды, будет деградация.
Лучше в имеющемся пуле жестко ограничить сверху количество рабочих тредов (слотов), один из которых пустить на "долгие" запросы. Как Вам тут уже подсказали, нужно будет сделать 2 очереди — для отложенных "быстрых" и "долгих" запросов.
Если свободные слоты кончились, поступивший новый запрос пихается в очередь "быстрых" запросов.
10 раз в секунду диспетчер перебирает занятые слоты и смотрит, сколько времени какой запрос выполнялся. Если более 5 секунд, ставит ему признак "долгий".
Далее логика простая — если очередь быстрых запросов не пуста, и долгие запросы, находящиеся в выполнении, занимают более одного слота, то случайным образом оставляется лишь один долгий запрос, а остальные "долгие" — отстреливаются и помещаются в очередь "долгих". В освободившиеся слоты вынимаются запросы из "быстрой" очереди. Когда "долгий" запрос отработает, из очереди случайным образом выбирается новый "долгий" запрос и пускается на обработку. Если "быстрые" все отработали, "долгие" занимают все слоты, кроме одного.
Re: Обеспечение реактивности системы.
От: Sergei I. Gorelkin Россия  
Дата: 04.10.07 22:02
Оценка: +1
Здравствуйте, WolfHound, Вы писали:

<skipped>

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


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


Со временем более-менее понятно, тяжелый поток можно тормознуть, и он не будет занимать CPU. С памятью можно поступать примерно так:
— При поступлении нового запроса смотрим, сколько осталось памяти. Если ее меньше A %, прибиваем самый тяжелый запрос (или несколько самых тяжелых, до тех пор, пока памяти не станет больше B %).
— Когда запрос пытается отхапать себе память, опять же проверяем, сколько ее осталось. Если ее меньше C %, прибиваем самый тяжелый запрос, или несколько, пока памяти не станет больше D %.
Подобрав экспериментально числа A, B, C и D, наверное, можно улучшить ситуацию.

Далее, вместо прибивания запроса насмерть его можно скидывать "в своп", а потом возобновлять. Дискового пространства по-любому больше, чем памяти.
Если запросу судьба выполняться 20 минут, а его прибили на 19-й, то при повторном выполении общее время составит 39 минут, а при свопинге — (20+пауза+время свопинга), выигрыш получается если (пауза+время свопинга) < 19 минут. Понятно, что приделывание сериализации состояния — это тоже трудозатраты, тем не менее это относительно стандартная и понятная задача.

Наконец, можно попытаться предсказывать вменяемость запроса не по нему самому, а набрав статистики по уже выполненным запросам. Подозреваю, что лог запросов уже ведется, добавить к нему время выполнения и расход памяти — дело техники. Чтобы проанализировать эту кучу информации, возможно придется что-то написать, но это опять же довольно стандартно. А дальше уже зависит от полученных результатов.
Re[4]: Обеспечение реактивности системы.
От: Sinclair Россия https://github.com/evilguest/
Дата: 05.10.07 08:13
Оценка:
Здравствуйте, DerBober, Вы писали:

DB>Можно ли перетащить выполняющийся запрос на другую машину? Например остановить вычисления и запустить на другой машине сначала. Результат от этого изменится?

Ничего из этого не поможет.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re: Обеспечение реактивности системы.
От: maloi_alex СССР  
Дата: 05.10.07 15:23
Оценка:
Здравствуйте, WolfHound, Вы писали:

Мне кажется, при такой проблеме, нужно копать в сторону создания плана запроса. Как это делается в разных СУБД.
Вопрос интересный. Буду следить за развитем событий.
Re: Обеспечение реактивности системы.
От: Maxim S. Shatskih Россия  
Дата: 05.10.07 16:18
Оценка:
Снять ограничение на число нитей в пуле. Переделать пул.

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

Но это только вопрос обеспечения ресурсом "нить". Наверняка там еще и какой-то локинг есть, на него бы посмотреть. Не будет ли так, что клинический запрос держит лок не отпуская все это клиническое время?
Занимайтесь LoveCraftом, а не WarCraftом!
Re[2]: Обеспечение реактивности системы.
От: WolfHound  
Дата: 05.10.07 17:49
Оценка:
Здравствуйте, Maxim S. Shatskih, Вы писали:

MSS>Снять ограничение на число нитей в пуле. Переделать пул.

Запросам нужно много памяти...

MSS>Но это только вопрос обеспечения ресурсом "нить". Наверняка там еще и какой-то локинг есть, на него бы посмотреть. Не будет ли так, что клинический запрос держит лок не отпуская все это клиническое время?

Локинга там нет.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[3]: Обеспечение реактивности системы.
От: Maxim S. Shatskih Россия  
Дата: 05.10.07 20:19
Оценка:
MSS>>Снять ограничение на число нитей в пуле. Переделать пул.
WH>Запросам нужно много памяти...

Реальна ли ситуация, когда поступает столько клинических запросов, что они пожирают _всю память_?

Если да — то лимитирующий ресурс тут память, а не пул, и, видимо, никак не обойтись без того, чтобы оценить "клиничность" запроса еще до того, как он начал жрать память, и на основании оценки уже что-то делать — например, в очередь поставить.
Занимайтесь LoveCraftом, а не WarCraftом!
Re[5]: Обеспечение реактивности системы.
От: Eugene Kilachkoff Россия  
Дата: 05.10.07 21:07
Оценка:
Здравствуйте, WolfHound, Вы писали:

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

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

То есть, получается примерно так: каждая задача отжирает 5% памяти, и более 20 одновременных задач вгоняют систему в жестокий свопинг и вообще. Так чтоли? И, соответственно, динамическое изменение размера пула не подходит.


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

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

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


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

WH>Запрос это некий пакет данных который обрабатывается.
WH>Соответственно его обработку можно на пол пути прибить и начать заново.
WH>Но обрабатывать нужно по возможности в реальном времени ибо пользователи ждут ответ.
WH>А те кто задали клинический запрос пусть ждут но при этом не мешают другим.

Т.е. отказы с просьбой повторить позже допустимы?


На мой взгляд проблема распадается на две:
1. Обнаружение (или предсказание) starvation.
2. Реакция на эту ситуацию.

Если честно, то я не очень вкурил какой спектр допустимых решений по обоим проблемам. К примеру, ты пишешь что предсказать сложность невозможно (точнее, сложность предсказания примерно совпадает со сложностью собственно обсчета задачи). А что вообще можно? То же самое и по второму пункту. Дропать вроде бы можно. А "поставить на паузу"? А отменить вообще и перекинуть кому либо еще? А отменить и затолкать в очередь чтобы оно там отлежалось (освободив, понятно, ресурсы, иначе это не имеет смысла)?

Если совсем от фонаря, то идея примерно такая. Каким либо образом обнаруживается количество долгих запросов в пуле (либо сканированием по таймеру, либо путем изменения глобального счетчика если обработчик детектит запрос как долгий, не суть). Когда доля долгих запросов начинает превышать некий процент (какой именно определяется либо экспериментально, либо моделированием, либо теоретическими расчетами) пулу выставляется флаг "starving", что заставляет обработчики дропать новые запросы если они оказываются долгими. Старые в это время обрабатываются нормально. Понятно, тут возможны вариации на тему динамического определения порогов вхождения в режим starvation и выхода из него, итэдэ, итэпэ. Такой вариант подходит?
Re[4]: Обеспечение реактивности системы.
От: WolfHound  
Дата: 06.10.07 05:48
Оценка:
Здравствуйте, Maxim S. Shatskih, Вы писали:

MSS>Если да — то лимитирующий ресурс тут память, а не пул, и,

Я в первом сообщение писал что есть 2 лимитирующих фактора CPU и память. CPU заканчивается чуть раньше память чуть позже.
По тому и пул потоков маленький.

MSS>видимо, никак не обойтись без того, чтобы оценить "клиничность" запроса еще до того, как он начал жрать память, и на основании оценки уже что-то делать — например, в очередь поставить.

Определить до начала работы не получится.
Можно определить во время работы пока запрос еще не слишком долго обрабатывался.
Памяти он сожрать успеет много но процессора мало.

По всей видимости придется делать так:
Доработать пулы таким образом чтобы можно было делать вложенные пулы.
Те есть общий пул О и есть пул для клиничиских случаев К.
Пул К использует потоки пула О но лимит пула К меньше чем пула О.
Таким образом даже если пул К будет забит в пуле О будут свободные потоки.
Но общее колличество потоков будет таким чтобы система все еще нормально жила.

При обнаружении клинического случая перемещаем его в пул К.
Если превышен лимит пула К то пристреливаем и ставим в очередь пула К.

Таким образом при нормальной работе не произойдет никакой деградации по сравнению с тем что есть сейчас.
Но при наплывах тяжолых запросов реактивность системы хоть и снизится но незначительно.
... << RSDN@Home 1.2.0 alpha rev. 745>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re: Обеспечение реактивности системы.
От: Sinclair Россия https://github.com/evilguest/
Дата: 06.10.07 08:10
Оценка: 6 (2) +3
Здравствуйте, WolfHound, Вы писали:

Ну, в общем, способ, действительно, ровно один.

Итак, все невыполненные задания делятся на тяжелые и неизвестные.
Тяжелые — те, выполнение которых требует больше MaxLight времени.
Неизвестное задание — те, которые потратили меньше MaxLight времени, но еще не закончились.
Очередей мы делаем две: очередь тяжелых и очередь неизвестных.
Все новые задания попадают в очередь неизвестных.

Если после занятия последнего пула в свопе прошло больше MaxLight, то значит у нас весь пул забит тяжелыми заданиями. (Все остальные задания начались еще раньше, так что тоже потратили больше MaxLight). Стратегия такова: мы пристреливаем самое недавнее тяжелое задание, и переводим его в очередь тяжелых.
Последний свободный слот может занять только неизвестное задание. Тяжелые задания обрабатываются только после исчерпания очереди неизвестных.

Проблемы:
Тяжелые запросы будут долго отлеживаться в очереди. Предположим, в нас в пуле 5 слотов. Перемещение задания в очередь тяжелых означает, что у нас уже выполняется 4 тяжелых задания. Пристрел освобождает один слот, и мы занимаем его очередной неизвестной задачей. Далее происходит одно из трех:
1. Новое задание заканчивается быстрее, чем через MaxLight.
2. Новое задание не заканчивается за MaxLight -> оно оказалось тяжелым.
3. Какое-то из четырех тяжелых заданий заканчивается и освобождает слот

Ни в одном из этих случаев мы не извлекаем заданий из тяжелой очереди: освободившийся слот (ровно 1) будет занят одним из неизвестных заданий.
При этом вариант 3 означает, что у нового задания появился шанс проработать больше MaxLight и не быть пристреленным. В итоге, приоритет получают тяжелые задания, лежащие в очереди неизвестных.

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

Предложенная схема минимизирует непроизводительные потери времени. Каждое тяжелое задание съедает либо NaturalLength (удалось выполнить с первого раза) либо NaturalLength+MaxLight (при рестарте). Повторных рестартов не будет никогда.

В случае, если есть способ "усыпить" задание вместо его убийства, потери будут еще меньше.
Легкое задание, вставшее в очередь под номером N, гарантированно будет выполнено через N*MaxLight времени.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[5]: Обеспечение реактивности системы.
От: DerBober США  
Дата: 06.10.07 12:08
Оценка:
Здравствуйте, Sinclair, Вы писали:

DB>>Можно ли перетащить выполняющийся запрос на другую машину? Например остановить вычисления и запустить на другой машине сначала. Результат от этого изменится?

S>Ничего из этого не поможет.

Ёмкий ответ.

Зачем сами предлагаете метод
Автор: Sinclair
Дата: 06.10.07
основанный на перетаскивании запросов между пулами/машинами? Все равно же не поможет.
Re[6]: Обеспечение реактивности системы.
От: Sinclair Россия https://github.com/evilguest/
Дата: 08.10.07 02:13
Оценка:
Здравствуйте, DerBober, Вы писали:
DB>Ёмкий ответ.
DB>Зачем сами предлагаете метод
Автор: Sinclair
Дата: 06.10.07
основанный на перетаскивании запросов между пулами/машинами? Все равно же не поможет.

Поясняю: само по себе перетаскивание ничего не даст. Считайте, что у вас вместо двух машин одна, в два раза более мощная.
Отличие моего предложения — в том, что нет двух пулов, есть только один со специфическими правилами разгребания очереди. Если идут только "легкие" запросы, то для них используется всё оборудование, какое есть.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re: Обеспечение реактивности системы.
От: ArtDenis Россия  
Дата: 10.10.07 18:13
Оценка:
Здравствуйте, WolfHound, Вы писали:

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


Ничего не надо прибивать. Послывешь сигнал демону, который обрабатывает клинический запрос, чтобы он сбросил текущие данные в памяти на диск, освободил память и уснул. Как только наплыв коротнких запросов уменньшиться до определённого уровня, посылаешь сигнал, демон просыпается, восстанавливает копию данных с диска м продолжает работу с остановленной точки. Естессно логика обработки должна поддерживать возможность приостановки и возобновления.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
[ 🎯 Дартс-лига Уфы | 🌙 Программа для сложения астрофото ]
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.