«Мягкий» real-time

И да, над всем этим бдительно смотрит WatchDog, который вопит и устаривает истерику, если кто-то из "боевиков" типа QueueRunner, Recorder или Networker вдруг не подает признаки жизни в течение нескольки (10...15) секунд.

этСтавишь линух, делаешь самый минимальный своп, отключаешь все сервисы, выносишь лишнее из крона, автообновления итп что может дёргать тачку. Отключи компрессию логов. Тюнишь некоторые sysctl типа vm.swappiness=0. Следишь чтобы был всегда многократный запас производительности... и всё.

> Следишь чтобы был всегда многократный запас производительности...

И потом кто-нибудь в базе делает lock tablename

> и всё.

Ага, точно "все" :-)

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

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

> Следишь чтобы был всегда многократный запас производительности... и всё.

Ыыыы... какой кошмар %)

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

> И потом кто-нибудь в базе делает lock tablename

Кто? Барабашка?

> Ыыыы... какой кошмар %)

Выскажи свою некошмарную идею.

> Выскажи свою некошмарную идею.

Понимаешь, некошмарной идеи нет... если кратко, то система должна давать гарантии "by design" - есть разные специальные техники для этого. То есть, должна быть спроектирована специальным образом (но-дачи так и сделал). А ты вообще считаешь (судя по твоему постингу), что специальное проектирование не нужно.

> Есть какие-нибудь мысли как ЭТО все улучшить?

А что конкретно сейчас не устраивает?

Можно не жадные до процессора треды свести в один, который будет работать асинхронно.

Ingo Molnar писал патчи как раз для такого варианта realtime.

> А ты вообще считаешь (судя по твоему постингу), что специальное проектирование не нужно.

Ничего подобного. То что я сказал я считаю "специальным проектированием" из подручных средств. Т.е. не просто мощный сервак впиндюрить предлагаю, я предлагаю заранее подумать где может быть затык(напр. "отключить компрессию логов") и попытаться его устранить. Вот чтоб это не залагало в неподходящий момент("DBThread тормозит, например") нужен запас производительности. И тесты всего этого в боевых условиях. И некоторый тюннинг системы.

>> А ты вообще считаешь (судя по твоему постингу), что специальное проектирование не нужно.

> Ничего подобного.

"Ничего подобного" было бы, если бы ты сам не сказал "и всё".

> Ingo Molnar писал патчи как раз для такого варианта realtime

По опыту, наибольшее количество проблем создает как раз не операционка, а база данных. Она может находиться на другом компе, СУБД может просто "тормозить" из-за своих внутренних мыслей и т.п.

В общем, предложенная схема сработала, поставленная задача решена. Конечно, надо еще все переписать "набело", но в третьем приближении система пиковый удар держит :-)

> И некоторый тюннинг системы.

Тюнинг дает проценты производительности. Дизайн дает прирост в порядки :-)

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

> Тюнинг дает проценты производительности. Дизайн дает прирост в порядки :-)

Как старый админ говорю-ты не прав :). Без правильно настроенной тачки ничего работать толком не будет. С другой стороны, а что считать тюнингом? Индексы в базе расставить это тюннинг? Логи вынести на отдельный винт? Итп. Это можно рассматривать как тюнинг так и часть дизайна.

> может просто "тормозить" из-за своих внутренних мыслей и т.п.

База делает то что ты ей скажешь. Сама по себе она запросы выполняет.

Слушай, старый админ, шел бы ты в Admin, и не мешал дядькам программистам обсуждать серьезные вещи :))

если по делу, то тут наверное будет очень важдым выбор СУБД...

может всю эту "клюкву" написать на Erlang, и заюзать "софт-реалтайм" СУБД Mnesia? ;)

Удачи!

> База делает то что ты ей скажешь. Сама по себе она запросы выполняет.

Данные в базе нужны для того, чтобы их впоследствии читали и с ними работали. И все эти инджексы и прочее для OLTP как мертвому припарка, а часто даже скорей как больному цианид. OLTP - это много мелких insert/update и крайне прсотые select вида select id from table wheer value=:name, здесь оптимизации места просто нет.

По жизни я администрирую ораклы, и могу сказать сразу, что редизайн (переписывание запроса, использование материализованных представлений, правильное подтягивание функций и т.п.) дает прирост в разы, а то и в десятки раз, индексы и прочее - на проценты (в лучшем случае - на десятки процентов).

Мы строили индексы, читали планы запросоы, оптимизировали распределение датафайлов по носителям, смотрели выводы статспаков и всякой муетни и занимались прочей чушью... И как мы гордились, когда оборотная ведомость начала формироваться за 10 минут а не за 20... А потом наш главный "оптимизатор" уволился. Да. И поскольку смотреть на всякие latch waits и прочую пое..нь мне надоело, то я занялся нормальной работой с перепроктированием запросов. Какие результаты? Для сравнения, некоторый отчет собирался 10-15 минут, после переписывания начал собираться за 10-15 секунд. Баланс собирался 8-12 часов, стал собираться за 5-15 минут. Это проектирование :-)

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

Индексы не нужны? Даже если у тебя все запросы с where id=... то индекс всё равно используется потому что это primary key. Но только в жизни такими простыми запросами OLTP не ограничивается. И тут я могу привести хороший пример. Добавление индексов на поля которые используются в where удалось сократить время исполнения запроса с 7 секунд до 0.13. Вполне сравнимо с "Баланс собирался 8-12 часов, стал собираться за 5-15 минут".

Другой пример. Настроил ты десяток машин в кластере. И забыл какой-нить updatedb из крона выкинуть. В результате ночью одновременно у всех тачек резко напряглись винты и кластер резко залагал. А тут ещё ротация логов с бэкапами подоспела. Вообще труба. Особенно если у кластера не было значительного запаса по производительности.

Или какие-нить mbufы кончатся и тачка выпадет из сети.

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

> И забыл какой-нить updatedb из крона выкинуть. В результате ночью одновременно у всех тачек резко напряглись винты и кластер резко залагал. А тут ещё ротация логов с бэкапами подоспела.

Жжошь. На боевых серверах производительность подсистем I/O под тяжелыми СУБД такая, что они все примонтированные ФС поднимают в кэш за несколько секунд, датафайлы СУБД вообще на отдельном сторадже, и все эти такие "страшные" по твоему мнению процессы на скорость обращения к ним не повлияют в принципе. Проверено :-)

> Но только в жизни такими простыми запросами OLTP не ограничивается.И тут я могу привести хороший пример. Добавление индексов на поля которые используются в where удалось сократить время исполнения запроса с 7 секунд до 0.13.

Плохой пример. OLTP как раз раз ограничивается крайне простыми запросами (а приведенный тобой случа как раз крайне простой), поскольку основные операции там как раз поиск в справочнике по ключевым атрибутам. А ключевые атрибуты, как известно, ясны уже на этапе постановки задачи, то есть индексы для них построены на этапе проектирования БД. Увы.

Опять таки - в журналируемых версионных СУБД (а назови сейчас не такую?) операция записи в три-пять раз медленнее операции чтения, плюс конкуренция за совместно изменяемые объекты (если такие есть)... Не зря в настрйоках "шаблонов" для создания базы оракла есть два готовых темплейта - Transaction processing и Data warehouse.

> Без допиливания настроек ОС и сопутствующих компонентов зачастую не обойтись

Как раз обходится, совершенно естественным образом. Для soft-realtime систем критична как раз архитектура "думающей" части системы, а не операционка. На одном и том же железе оракел под виндами, под солярисом и под линуксом покажет примерно одинаковую производительность, при условии невыхода нагрузки системы на "закритический" режим. "Тонкий тюнинг" операционки нужен только при неправильном развертывании СУБД (чего правда очень много).

> Я сказал что чтобы всё работало нормально все компоненты системы должны работать нормально

Как бы "нормально" не работала операционка под сервером логики, о котором шла речь в самом начале, ЕСЛИ БЫ все это было сделано в одном потоке, пусть и с использованием всяческих select() и poll(), то в случае замедления СУБД по любой причине, программа также встала бы на неопределенное время

Первый вариант (когда было не было жестких требований по времени реакции) реализовывался именно так, без нити DBThread. Последствия были неприятны - постоянные жалобы пользователей и лаги, попытки подлатать программу то тут, то там и так далее.

Впрочем, "админ программера не разумеет" :-)

> ЕСЛИ БЫ все это было сделано в одном потоке, пусть и с использованием всяческих select() и poll(), то в случае замедления СУБД по любой причине, программа также встала бы на неопределенное время

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

Устал спорить. Если у вас такие могучие железки которые всё стерпят то вам это действительно не надо.

Присоединяюсь к вопросу mv: "А что конкретно сейчас не устраивает?"

Может имеет смысл делать отельный процесс middleware, который будет работать с СУБД, буферезировать UPDATE, кешировать справочники из БД. Ваша программа взаимодействует с ним через UNIX-socket'ы, процесс многопоточный или работает с БД асинхронно.

И я не совсем понял фразу:

>Если клиенту надо "срочно" вернуть ответ, Networker может прочесть данные из записи, хранящейся в QueueRunner.

То есть обращаемся не к очереди "грязных" объектов, хранящейся у DBThread, которая и должна быть самая большая, так как БД непредсказуема, а именно к очереди QueueRunner?

> То есть обращаемся не к очереди "грязных" объектов, хранящейся у DBThread, которая и должна быть самая большая, так как БД непредсказуема, а именно к очереди QueueRunner?

Объекты в QueueRunner постоянно рождаются и умирают по командам от Recorder. По командам от Networker у объектов меняются атрибуты, и ответа такие команды не требуют, но есть одна специфическая команда LINE_STATE, по приходу которой необходимо сделать ответ "текущее состояние опрашиваемой линии такое-то". То есть вся работа именно с QueueRunner.

В момент когда объект рождается, он записывается в два списка - в список "активных" в QueueRuneer и список "известных" у DBThead. Если QueueRunner изменил объект, DBThread сохранит его когда руки дойдут. Как только QueueRunner решил что объект должен умереть, он ставит на нем метку "более не нужен", и кода DBThread заканчивает с ним работать, объект окончательно уничтожается.

> Может имеет смысл делать отельный процесс middleware

IMHO, это нагромождение сущностей и сложностей вне меры