#dba #postgres #troubleshooting
Целая эпопея с тестированием СУБД. В свете предыдущего поста, у меня появилось несколько вариантов организации данных в табличке. Как человеку приличному, захотелось их объективно сравнить как по занимаемому на диске месту, так и по скорости вставки и чтения данных. Понятно, что замерять для это придётся несколько раз, и оценивать среднее и разброс. Также ясно, что после первого запроса данные уже будут в кэше, и остальные сравнения будут необъективны. Естественно, приходим к необходимости сброса кэшей. Оказывается, в постгре такого нет, сброс достигается только полным рестартом инстанса. Ну ладно, думаю, тогда хотя бы как рестартить инстанс СУБД sql запросом, наверняка же можно? Нет такого. Ладно, откапываем питоновский язык plpython3u и учимся его ставить на сервер. Теперь-то можно с помощью subprocess запускать системную команду sudo service postgresql restart? Фиг там... Инстанс-то запущен под отдельным несистемным юзером. Ну ладно, а pg_ctl-ом то можно? Оказывается, можно потушить с помошью /usr/lib/postgresql/15/bin/pg_ctl stop -D /var/lib/postgresql/15/main. А вот перезапустить не получается, потому что родительский процесс при остановке инстанса умирает, убивая дочерний, который уже не может осуществить запуск нового инстанса. Так и сижу целый день. Придётся лезть на сервер и там тестировать локальным скриптом.. Ну или плюнуть на очистку кэшей и объективность результатов. Тем более что файловый кэш ОС всё равно останется.
Целая эпопея с тестированием СУБД. В свете предыдущего поста, у меня появилось несколько вариантов организации данных в табличке. Как человеку приличному, захотелось их объективно сравнить как по занимаемому на диске месту, так и по скорости вставки и чтения данных. Понятно, что замерять для это придётся несколько раз, и оценивать среднее и разброс. Также ясно, что после первого запроса данные уже будут в кэше, и остальные сравнения будут необъективны. Естественно, приходим к необходимости сброса кэшей. Оказывается, в постгре такого нет, сброс достигается только полным рестартом инстанса. Ну ладно, думаю, тогда хотя бы как рестартить инстанс СУБД sql запросом, наверняка же можно? Нет такого. Ладно, откапываем питоновский язык plpython3u и учимся его ставить на сервер. Теперь-то можно с помощью subprocess запускать системную команду sudo service postgresql restart? Фиг там... Инстанс-то запущен под отдельным несистемным юзером. Ну ладно, а pg_ctl-ом то можно? Оказывается, можно потушить с помошью /usr/lib/postgresql/15/bin/pg_ctl stop -D /var/lib/postgresql/15/main. А вот перезапустить не получается, потому что родительский процесс при остановке инстанса умирает, убивая дочерний, который уже не может осуществить запуск нового инстанса. Так и сижу целый день. Придётся лезть на сервер и там тестировать локальным скриптом.. Ну или плюнуть на очистку кэшей и объективность результатов. Тем более что файловый кэш ОС всё равно останется.
⚡1