Может замедлить в реальном времени убить тикерплант в KDB - PullRequest
Новая
       10

Может замедлить в реальном времени убить тикерплант в KDB

0 голосов
/ 22 марта 2020

Может ли медленный потребитель убить или замедлить работу тикерплана?

У меня есть тикерная станция, у которой 3 подписчика в режиме реального времени, один из которых медленный. 

q).z.W
7 | `long$()
8 | 969393 198 198 197 197 198 196 199 197 196 143 198 196 196 197 197 198 19..
9 | 199 198 198 143 197 199 197 197 197 197 199 196 199 145 196 198 198 198 1..
10| 198 196 198 144 199 198 198 198 196 197 196 199 198 143 199 198 197 198 1..

q)count each .z.W
7 | 0
8 | 85547
9 | 77931
10| 0

q)count each .z.W
7 | 0
8 | 191552
9 | 0
10| 0

Может ли медленный потребитель получить tickerplant убил или замедлил его в производственных системах kdb +, получающих миллиарды записей?

Ответы [ 2 ]

4 голосов
/ 22 марта 2020

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

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

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

2 голосов
/ 23 марта 2020

Ответ Терри на 100% правильный. Я просто хочу рассказать о необходимости сбора мусора в TP с медленными подписчиками.

Важно, чтобы эта коллекция была реализована с помощью .Q.gc[], а не с помощью немедленной коллекции \g 1. Непосредственная коллекция запускается только тогда, когда все ссылки на объект отбрасываются и объект возвращается в кучу, если его размер превышает 64 МБ, триггеры коллекции запускаются.

Во время обычного выполнения в TP опубликованные данные никогда не являются ссылочными объектами, это параметры входящего сообщения, которое затем публикуется. Из-за этого не существует разыменования объекта, который запускает автоматическую сборку мусора c.

...