38 ответов в этой теме

[pig]

Хм... а велика ли база?

[Александр Б.]

Хм... а велика ли база?

 

postgres=# SELECT pg_size_pretty( pg_database_size('drwebes') );

 pg_size_pretty 

----------------

 22 GB

(1 row)

[Александр Б.]

Оставление на ночь не помогло, обновление не встало, вернулось к версии 18 ноября.

 

Сейчас с изумлением наблюдаю насколько стал медленней веб-интерфейс, заодно процессорную загрузку сервера:

 

в обычные дни постгрес потребляет 1-5% и это когда 1500 станций онлайн. 

 

сейчас их не больше 1000.

[Александр Б.]

Сейчас с изумлением наблюдаю насколько стал медленней веб-интерфейс, заодно процессорную загрузку сервера:

 

Вроде всё устаканилось, веб-интерфейс стал адекватен. Подозреваю я включил по утру Анализ/Чистку БД в разделе Администрирование и совершенно забыл про это.

[Kirill Polubelov]

22ГБ размер БД, а сколько ж у вас станций?

[Александр Б.]

зарегистрировано ~1700, в средний онлайн обычно ~1350

[Kirill Polubelov]

Ага, кое-что проясняется:

egrep -a " ERR | FTL " updater-revert.log
20200318.082719.21 ERR [39128 39128] main   [PgSQL/1] Unable to create instance because of
20200318.082719.21 ERR [39128 39128] main   [PgSQL/1] \ unable to connect TCP socket to server XXX.XXX.XX.XX because of
20200318.082719.21 ERR [39128 39128] main   [PgSQL/1] \ В соединении отказано (errno=111)
20200318.082719.21 ERR [39128 39128] main   [PgSQL/1] exceptions_namespace::socket_exception: unable to connect TCP socket to server XXX.XXX.XXX.XXX because of В соединении отказано (errno=111)
20200318.082719.28 ERR [39128 39128] main   [DBPool] Unable to create [PgSQL/1] connection because of Unable to connect TCP socket to server XXX.XXX.XXX.XXX because of В соединении отказано (errno=111)
20200318.082719.38 ERR [39128 39128] main   [Server] Server execution failed because of
20200318.082719.38 ERR [39128 39128] main   [Server] \ no DB connections have been created
20200318.082719.38 ERR [39128 39128] main   [Server] exceptions_namespace::config_exception: no DB connections have been created

 

egrep -a " ERR | FTL " updater-update.log
20200318.001641.34 ERR [10346 10346] main   [PgSQL/1] Could not extend file "pg_tblspc/16385/PG_9.5_201510051/16386/3459976": На устройстве не осталось свободного места. Check free disk space. (S:53100 ERROR), 01:02.739, INSERT INTO cat_users_DFB9moyXN6 SELECT username FROM station_appctl_event

 

Попутно вопрос -- во втором архиве только drwcsd.6.log.gz, с др. номерами (5,4,3,2,1) не было?

[Kirill Polubelov]

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

[Aleksandra]

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

Ну, не знаю.

[root@localhost aleksa]# du -sh /var/lib/pgsql/
2,6G    /var/lib/pgsql/
[root@localhost aleksa]# su - postgres
Последний вход в систему:Ср мар 18 14:42:38 +05 2020на pts/0
[postgres@localhost ~]$ psql
psql (10.6)
Введите "help", чтобы получить справку.

postgres=# select pg_size_pretty(pg_database_size('drwcs'));
 pg_size_pretty
----------------
 2520 MB
(1 строка)

На таком же количестве станций и с работающим контролем приложений.
 

[Kirill Polubelov]

На таком же количестве станций и с работающим контролем приложений.

Вопрос не в работающем КП, как таковом, а в его настройках.

[Aleksandra]

 

На таком же количестве станций и с работающим контролем приложений.

Вопрос не в работающем КП, как таковом, а в его настройках.

 

Тогда интересно, что так могло раздуть БД у ТС?

[Александр Б.]

Попутно вопрос -- во втором архиве только drwcsd.6.log.gz, с др. номерами (5,4,3,2,1) не было?

 

самый старый файл (на момент начала обновления)  drwcsd.log и самый новый я приложил.

 

промежуточные были одного размера и, подозреваю, с одним содержимым.

 

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

 

Это, кстати, странно.

 

На момент начала обновления на сервере было свободного гигабайт 40 (это при том, что объем данных вместе с осью суммарно 35гб)

 

Правда до прошлого обновления (18 ноября) не было контроля приложений и поэтому объем базы был сильно меньше.

 

Попробую тогда вечером добавить еще гигабайт 40 и снова попытаться обновиться. 

 

Интересно сколько же нынче для обновления нужно места свободного.

[Александр Б.]

 

 

На таком же количестве станций и с работающим контролем приложений.

Вопрос не в работающем КП, как таковом, а в его настройках.

 

Тогда интересно, что так могло раздуть БД у ТС?

 

 

Обнаруженные устройства только за сегодня (список загружался минуты 3):

Сообщение было изменено Александр Б.: 18 Март 2020 - 13:48

[Aleksandra]

На таком же количестве станций и с работающим контролем приложений.

Вопрос не в работающем КП, как таковом, а в его настройках.

Тогда интересно, что так могло раздуть БД у ТС?

 
Обнаруженные устройства только за сегодня (список загружался минуты 3):

Почти такой же, 844860.

[Александр Б.]

 

 

 

 

На таком же количестве станций и с работающим контролем приложений.

Вопрос не в работающем КП, как таковом, а в его настройках.

 

Тогда интересно, что так могло раздуть БД у ТС?

 

 
Обнаруженные устройства только за сегодня (список загружался минуты 3):

 

Почти такой же, 844860.

 

 

Справочник приложений:

[Aleksandra]

Справочник приложений:

Вот здесь десятикратный перевес.

[Александр Б.]

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

 

Сейчас база весит 18гб, при этом Контроль Приложения сам включился обратно.

[Kirill Polubelov]

Вы молодец (без иронии).

[Afalin]

К слову, внезапно обнаружилось, что события блокировки устройств и контроля приложений не чистятся. В отличие от всего остального, что живёт 90 суток.

Это как раз может дополнительно раздувать объём БД.