PostgreSQL: вынос pg_stat_tmp на рамдиск - насколько это безопасно?
Уважаемые коллеги, обсуждения в соседних ветках заставили вспомнить один простой прием повышения производительности PostgreSQL.
Дело в том, что при интенсивной работе с БД очень большое кол-во дисковых операций идет с каталогом pg_stat_tmp, в чем легко убедиться, выполнив во время интенсивной работы 1С sudo inotifywatch -e /var/lib/pgsql/ и подождав минут 5-10, пока соберется достаточно статистики.
Вынос этого каталога в рамдиск - чуть ли не стандартная процедура для больших БД.
Объем там большой не требуется, и с многократным запасом хватит 1 ГБ. В общем, надо добавить в /etc/fstab строчку
tmpfs /var/lib/pgsql/data/pg_stat_tmp tmpfs noatime,nodiratime,size=1000M,mode=700,uid=36,gid=36
где uid и gid определяются командой id postgres.
ну и mount -a
Все просто.
Кто-нибудь так делал?
Насколько это безопасно? Например, если сервер запитан от обычного БП Delta, не самого плохого, но, к сожалению, одиночки, без дублера. ИБП APC Smart 3000 есть, nut настроен и работает.
В принципе, вопрос: что произойдет с БД, если просто во время работы выдернуть шнур питания? Вся остальная дисковая система - аппаратный рэйд с батарейкой.
Да, память ecc-шная, иначе смысла в этом нет, ИМХО. Или ошибаюсь?
Дело в том, что при интенсивной работе с БД очень большое кол-во дисковых операций идет с каталогом pg_stat_tmp, в чем легко убедиться, выполнив во время интенсивной работы 1С sudo inotifywatch -e /var/lib/pgsql/ и подождав минут 5-10, пока соберется достаточно статистики.
Вынос этого каталога в рамдиск - чуть ли не стандартная процедура для больших БД.
Объем там большой не требуется, и с многократным запасом хватит 1 ГБ. В общем, надо добавить в /etc/fstab строчку
tmpfs /var/lib/pgsql/data/pg_stat_tmp tmpfs noatime,nodiratime,size=1000M,mode=700,uid=36,gid=36
где uid и gid определяются командой id postgres.
ну и mount -a
Все просто.
Кто-нибудь так делал?
Насколько это безопасно? Например, если сервер запитан от обычного БП Delta, не самого плохого, но, к сожалению, одиночки, без дублера. ИБП APC Smart 3000 есть, nut настроен и работает.
В принципе, вопрос: что произойдет с БД, если просто во время работы выдернуть шнур питания? Вся остальная дисковая система - аппаратный рэйд с батарейкой.
Да, память ecc-шная, иначе смысла в этом нет, ИМХО. Или ошибаюсь?
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
В общем так: добавилось примерно 5 ед. по тесту Гилева, теперь от 39 до 43. Тест нельзя считать полностью адекватным, т.к. 15 пользователей работают, выполняются фоновые задания, автовакуум и т.п. Будем посмотреть дальше.
(5) ansh15, хорошая идея, конечно, я об этом читал и думал в свое время, остановила фраза из приведенного Вами обсуждения:
What disadvantages if to turn barriers off?
BTW I didn't tried jet.
Exactly what you wrote: risk of "severe file system corruption and data loss ... in case of power failure."
Тут может быть все что угодно, от пропадания контакта на коннекторе питания винчестера или корзины, выбивания шнура питания из сервера, отключение не того ИБП, в конце концов - сам БП может сдохнуть, а он один, резервного нет.
ИМХО не стоит оно того. У меня сейчас совершенно однозначно все уперлось в процессор, вернее, в ТЧ. Думаю, больше из того, что есть, выжать уже не удастся - без риска для информации, конечно.
What disadvantages if to turn barriers off?
BTW I didn't tried jet.
Exactly what you wrote: risk of "severe file system corruption and data loss ... in case of power failure."
Тут может быть все что угодно, от пропадания контакта на коннекторе питания винчестера или корзины, выбивания шнура питания из сервера, отключение не того ИБП, в конце концов - сам БП может сдохнуть, а он один, резервного нет.
ИМХО не стоит оно того. У меня сейчас совершенно однозначно все уперлось в процессор, вернее, в ТЧ. Думаю, больше из того, что есть, выжать уже не удастся - без риска для информации, конечно.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот