VG
подскажите пожалуйста, heap_blks_hit учитывает файловый кеш OS или только shared buffers?
Size: a a a
2020 May 30
MM
подскажите пожалуйста, heap_blks_hit учитывает файловый кеш OS или только shared buffers?
Нет, речь про шаренный буфер только
VY
И часто приходится их крутить?
Не разу не трогал эти параметры ядра, возможно чего то не знаю.
Не разу не трогал эти параметры ядра, возможно чего то не знаю.
там где были замечены разрывы в сети по каким-то причинам (в том числе приложение ушло по таймауту раньше, чем запрос завершился из-за затыка) и ждать стандартные 2 часа — долго
ВК
там где были замечены разрывы в сети по каким-то причинам (в том числе приложение ушло по таймауту раньше, чем запрос завершился из-за затыка) и ждать стандартные 2 часа — долго
Спасибо почитаю.
У меня были в бою несколько инсталляций с сетевыми проблемами, дропали периодически пакеты, ждали в очереди приёма... помогало как правило либо повышение netdev_budget, netdev_max_backlog, tcp_max_syn_backlog, somaxconn.
Либо с сетевыми нагрузкам повыше, иногда настройка сетевых устройств:
количество очередей приёма, размер очереди сетевой карты, распредение прерываний по нескольким ядрам CPU - 'IRQ Balance'.
Но не раз не трогал tcp_keepalives.
У меня были в бою несколько инсталляций с сетевыми проблемами, дропали периодически пакеты, ждали в очереди приёма... помогало как правило либо повышение netdev_budget, netdev_max_backlog, tcp_max_syn_backlog, somaxconn.
Либо с сетевыми нагрузкам повыше, иногда настройка сетевых устройств:
количество очередей приёма, размер очереди сетевой карты, распредение прерываний по нескольким ядрам CPU - 'IRQ Balance'.
Но не раз не трогал tcp_keepalives.
VG
Нет, речь про шаренный буфер только
По потреблению памяти видно, что всю таблицу postgres не мог в шареные буферы положить. Получается, происходит в основном чтение малой части одних и тех же страниц
М
Ребята, концептуальный вопрос, подскажите пожалуйста, как правильно спроектировать БД под приложение
Есть таблица логов/транзакций/биллинг/процессинг - как хотите. Суть - наполнение ее записями по 300к в сутки
В приложении надо реалиовать поиск транзакций по дате и другим полям из этой таблицы. Ну например номер карты, статус операции
На данный момент любой поиск - это сканирование всей таблицы
Есть таблица логов/транзакций/биллинг/процессинг - как хотите. Суть - наполнение ее записями по 300к в сутки
В приложении надо реалиовать поиск транзакций по дате и другим полям из этой таблицы. Ну например номер карты, статус операции
На данный момент любой поиск - это сканирование всей таблицы
М
crm-# \d ivr.autoringup_call
Table "ivr.autoringup_call"
Column | Type | Collation | Nullable | Default
------------+-----------------------------+-----------+----------+-------------------------------------------------
id | integer | | not null | nextval('ivr.autoringup_call_id_seq'::regclass)
abon | character varying(13) | | not null |
datetime | timestamp without time zone | | not null |
dialtime | integer | | |
waittime | integer | | |
abmsgtime | integer | | |
msgtime | integer | | |
dialsignal | character varying(50) | | |
ringup | character varying(5) | | |
status | character varying(1) | | |
pc_id | character varying(8) | | |
project | character varying(10) | | |
type | integer | | |
Indexes:
"autoringup_call_pk" PRIMARY KEY, btree (id)
"autoringup_call_pc_id_datetime_idx" btree (pc_id, datetime DESC NULLS LAST)
М
explain (analyze, buffers)
select * from ivr.autoringup_call where datetime between '2020-05-21 00:00:00' and '2020-05-22 00:00:00'
Gather (cost=1000.00..286578.08 rows=152218 width=99) (actual time=585.538..661.873 rows=161274 loops=1)
Workers Planned: 2
Workers Launched: 2
Buffers: shared hit=2411 read=187418
-> Parallel Seq Scan on autoringup_call (cost=0.00..270356.28 rows=63424 width=99) (actual time=582.112..629.147 rows=53758 loops=3)
Filter: ((datetime >= '2020-05-21 00:00:00'::timestamp without time zone) AND (datetime <= '2020-05-22 00:00:00'::timestamp without time zone))
Rows Removed by Filter: 4226578
Buffers: shared hit=2411 read=187418
Planning Time: 0.781 ms
Execution Time: 668.502 ms
М
Вроде особых задержек пока нет, но волнение есть)
ДЛ
Ребята, концептуальный вопрос, подскажите пожалуйста, как правильно спроектировать БД под приложение
Есть таблица логов/транзакций/биллинг/процессинг - как хотите. Суть - наполнение ее записями по 300к в сутки
В приложении надо реалиовать поиск транзакций по дате и другим полям из этой таблицы. Ну например номер карты, статус операции
На данный момент любой поиск - это сканирование всей таблицы
Есть таблица логов/транзакций/биллинг/процессинг - как хотите. Суть - наполнение ее записями по 300к в сутки
В приложении надо реалиовать поиск транзакций по дате и другим полям из этой таблицы. Ну например номер карты, статус операции
На данный момент любой поиск - это сканирование всей таблицы
Если вам просто надо писать огромное количество логов и затем аналитику по ним считать, то лучше под эту задачу использовать колоночную базу. Например, Clickhouse. Postgres - СУБД общего назначения строчная. Не лучшее решение для этой задачи.
АФ
Ребята, концептуальный вопрос, подскажите пожалуйста, как правильно спроектировать БД под приложение
Есть таблица логов/транзакций/биллинг/процессинг - как хотите. Суть - наполнение ее записями по 300к в сутки
В приложении надо реалиовать поиск транзакций по дате и другим полям из этой таблицы. Ну например номер карты, статус операции
На данный момент любой поиск - это сканирование всей таблицы
Есть таблица логов/транзакций/биллинг/процессинг - как хотите. Суть - наполнение ее записями по 300к в сутки
В приложении надо реалиовать поиск транзакций по дате и другим полям из этой таблицы. Ну например номер карты, статус операции
На данный момент любой поиск - это сканирование всей таблицы
Лучше использовать timestamptz. И как минимум создать индекс по полю с датой
АФ
Возможно партиционирование по дням
Д
Всем привет, ребят, у меня есть таблица postgres в которой есть колонка array(string) . Мне нужно реализовать нечеткий поиск внутри этой таблицы и выдавать результатом весь массив в котором есть слово которое совпадает на 50% с поисковым словом(словосочетанием). Как можно это сделать в БД? Есть идеи?
ВК
Если вам просто надо писать огромное количество логов и затем аналитику по ним считать, то лучше под эту задачу использовать колоночную базу. Например, Clickhouse. Postgres - СУБД общего назначения строчная. Не лучшее решение для этой задачи.
Тоже думали не поставить ли CH, но специалиста по этой БД у нас нет.
Решили использовать PostgreSQL с расширением timescaledb, вполне не плохо.
Пишет сервис сейчас порядка 10млн строк в час.
Решили использовать PostgreSQL с расширением timescaledb, вполне не плохо.
Пишет сервис сейчас порядка 10млн строк в час.
ВК
Правда это не логи, а события с устройств. time series.
ВЯ
Я вот тоже пока в тесте timescaledb щупаю
MM
Тоже думали не поставить ли CH, но специалиста по этой БД у нас нет.
Решили использовать PostgreSQL с расширением timescaledb, вполне не плохо.
Пишет сервис сейчас порядка 10млн строк в час.
Решили использовать PostgreSQL с расширением timescaledb, вполне не плохо.
Пишет сервис сейчас порядка 10млн строк в час.
компрессию колонки с метриками юзали?
ВК
компрессию колонки с метриками юзали?
Нет ещё, ждал хотя бы версию 1.7.1 прежде чем включать в пром.
ВК
В пром 1.5.1, тогда это была новая фича, надо обновиться.
AP
Для time series метрик лучшее использовать Prometheus или victoriametrics