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

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

они теряются

иногда нет записи о начале, и прилетает сразу о конце сессии и наоборот

а данные важные очень

пиши в таблицу то, что приходит

вдруг оно просто не в том порядке придёт, что ты делать будешь?

я сортировкой на входе все делаю

сессия минимум пятиминутная

Тем более. В логе тип записи: начало сессии, конец сессии

тогда таблица сильно распухнет

почему?

Вообще, но должно такого рассинхрона быть, что событие конца сессии логгируется раньше начала

и не будет

если потерялось, то сразу останется одна запись

в обоих типах записей время старта - константа

соотвественно будут 2 одинаковые записи с разницей только в timeend поле

в обоих типах записей время старта - константа

Это как? Я пока понимю, что и начало и конец в одной записи на данный момент. Я предлагаю эти события разнести

В общем нужна реструктуризация

буду думать, как замутить проще

Спасибо, коллеги

Много теряется? Тср не вариант?

процент сложно сказать

Для начала индекс без условия по timeend. Уже должно полегчать

netflow не умеет tcp

тоже раздет его

с местом порешать нужно тогда

данных 2.5 ГБ а индексы будут раза в 3 больше

Гб или Тб?

ГБ

мне места дали пока всео 50ГБ

Ну должно хватит на индекс-то :)

данные хранить 5 лет

минимум

а 2.5 гб это за пару месяцев

Это на 5 лет 50Гб дали? :)

пока да :(

тут я дубли то и убиваю

А 2,5 Гб за сколько набежало?

Проще хранить так, как прилетает, ну партиции

А 2,5 Гб за сколько набежало?

4 месяца примерно

7,5 Гб в год. 37,5 Гб за 5 лет

Ну надо ещё 50Гб просить, чтоб на индексы и wal-логи хватало

Архивирование включено у вас?

wal хранится отдельно на системном диске, индексы там же

А объем wal в сутки какой?

Архивирование включено у вас?

archive_mode = off

А объем wal в сутки какой?

там копеечный вроде

Ээээ....

Т.е. wal вы не бэкапите?

не

wal_keep_segments какой у вас стоит?

закоменчено в конфиге, значит дефолтный для 9.6

Может всё приходящее в небольшую табличку, а когда начало и окончание сессии в ней появится переносить уже одной строкой в постоянную таблицу?

не

Т.е. на момент времени восстанавливаться не планируете?

нет)

Сделайте show wal_keep_segments

Ну ладно... Раз данные не критичны, то странно требование 5 лет хранить

Сделайте show wal_keep_segments

0

Вроде если 9.6 то там не wal_keep_segments

вам, может, ещё и реплику настроить? :)

Да что вы... Реплика и бэкап для трусов

то-то же

не мешайте саботировать запись нетфлоу, а то сделаете тут надёжную систему, и не потерять ничего :)

Надёжную систему?! Эммм...

да ещё и с защитой от потерь

Это ненаучная фантастика.

если по tcp снимать - это телнет на железку и парсить вывод команд

у железки проц дико нагружается

flow дешевле

Вроде если 9.6 то там не wal_keep_segments

Вы видимо путаете с xlog. Всё что было xlog в 9.6 стало wal. Обратное не верно :)

а складывать в базу только агрегаты нынче не модно ?

Вы видимо путаете с xlog. Всё что было xlog в 9.6 стало wal. Обратное не верно :)

Там стало независимо wal_keep_segments и max_wal_size

модно, для этого pipelinedb придумали

Там стало независимо wal_keep_segments и max_wal_size

Тем не менее wal_keep_segments это не отменяет

а зачем?

Там стало независимо wal_keep_segments и max_wal_size

Вообще оно уже с 9.5

https://www.postgresql.org/docs/9.4/static/wal-configuration.html There will always be at least one WAL segment file, and will normally not be more than (2 + checkpoint_completion_target) * checkpoint_segments + 1 or checkpoint_segments + wal_keep_segments + 1 files. Each segment file is normally 16 MB (though this size can be altered when building the server). You can use this to estimate space requirements for WAL. Ordinarily, when old log segment files are no longer needed, they are recycled (that is, renamed to become future segments in the numbered sequence). If, due to a short-term peak of log output rate, there are more than 3 * checkpoint_segments + 1 segment files, the unneeded segment files will be deleted instead of recycled until the system gets back under this limit. https://www.postgresql.org/docs/9.5/static/wal-configuration.html Independently of max_wal_size, wal_keep_segments + 1 most recent WAL files are kept at all times. Also, if WAL archiving is used, old segments can not be removed or recycled until they are archived. If WAL archiving cannot keep up with the pace that WAL is generated, or if archive_command fails repeatedly, old WAL files will accumulate in pg_xlog until the situation is resolved. A slow or failed standby server that uses a replication slot will have the same effect (see Section 25.2.6).

Здравствуйте подскажите чат по изучению английского языка

Здравствуйте подскажите чат по изучению английского языка

https://skyeng.ru/

Здравствуйте подскажите чат по изучению английского языка

Напомнило "Здравствуйте, это канал по аниме? Как пропатчить kde под FreeBSD?"

пока тут время офигительных вопросы задают, тоже вкину: как понять по списку процессов, из какого каталога запущен postgres? на серваке 2 инсталляции и обе с недефолтным путём, версии одинаковые есть процесс postmaster, путь к которому явно указан. можно ориентироваться на него, или этого недостаточно для однозначного определения?

хм, echo $PGDATA от юзера postgres выдаёт путь к той же инсталляции, что и postmaster

пока тут время офигительных вопросы задают, тоже вкину: как понять по списку процессов, из какого каталога запущен postgres? на серваке 2 инсталляции и обе с недефолтным путём, версии одинаковые есть процесс postmaster, путь к которому явно указан. можно ориентироваться на него, или этого недостаточно для однозначного определения?

htop с отображением tree (f5) подойдет?

увы, нет хтопа. зато есть аптайм почти в 2 года и околопанический страх даже дышать на это нечто

Думаю, достаточно. Остальные по PPID Ну или по PID смотреть /proc/$PID/environ и искать там PGDATA

хм, echo $PGDATA от юзера postgres выдаёт путь к той же инсталляции, что и postmaster

Не показательно. PGDATA от юзера совсем не обязана совпадать с PGDATA процесса. Скрипт запускающий процесс может установить ему (процессу) какой угодно PGDATA, как впрочем и другие переменные окружения

увы, нет хтопа. зато есть аптайм почти в 2 года и околопанический страх даже дышать на это нечто

Чет я туплю, а ps -eF | grep post не покажет путь?

Ситуация чуууть-чуть более весёлая, на самом деле. Есть триггер в заббиксе, который через sh-ник дёргает psql с выводом count по определённой таблице с where по определённому полю. Так вот там в параметрах подключения указан юзер postgres без пароля. Я проверил pg_hba.conf на обеих инсталляциях. Оба менялись последний раз аж в апреле. В одном подключения из локальной сети без пароля допускаются (local all postgres trust), в другом вроде как нет (строки с trust отсутствуют). Ручной запуск sh-шника выдаёт psql: fe_sendauth: no password supplied. Запуск содержимого под пользователем, от которого пароль известен, даёт значение больше порогового. Триггер загорелся чуть более суток назад.

Чет я туплю, а ps -eF | grep post не покажет путь?

так и смотрел изначально. вижу только кучу процессов с указанием юзеров бд, таблиц и ip-шек

+ несколько postgress: ... process и единственную строку с полным путём, соответствующую postmaster'у

"инсталляций" точно две? и обе запущены?

а tree на сервере стоит?

"инсталляций" точно две? и обе запущены?

точно две. запущена как минимум одна) обе ли — затрудняюсь ответить

а tree на сервере стоит?

лол, тоже нет

это древний rhel

Заббикс на том же сервере?