Обсуждение: Оптимизация на уровне ОС.

Здравствуйте, сообщество pgsql-ru-general.

Предлагаю обсудить тему выбора стратегии максимизации формулы
[быстродействие+надежность/стоимость железа] сервера PostgreSQL.

Вот мой проектный вариант, который еще нуждается в осмылении,
доработке и реализации в работающем варианте.

1. Каталог pgdata монтируется в ненадежном и быстром месте - RAID0 или
RAM-диске (если позволяет размер).
2. Каталог pg_xlog монтируется в надежном месте - RAID1.
3. Ежесуточно бакап баз данных в надежное место - RAID1.
4. Очень правильно настраиваются опции  раздела "WRITE AHEAD LOG"
файла конфигурации сервера. Журнал танзакций должен превышать суточную
наработку данных.

Комментарии.

Данная стратегия, насколько я понимаю, допускает более "медленное"
выполнение операций связанных с записью данных (RAID1) и что всегда
желательно - улучшение быстродействия при запросах выборки данных
(RAID0/RAM).

Для двух дисков для RAID1 и RAM-диска каждый раз при загрузке
операционной системы выполняется форсмажорный скрипт: dbinit ...;
pg_restore ...; <дополнение восстановленных баз данных "чужеродным"
pg_xlog (?)>
Допустим наличие трех дисков, тогда можно их одинаково разбить на ,
допустим, два раздела и всего получаем шесть разделов. Три раздела (по
одному с диска) относим в RAID0 для корня pgdata, два раздела - в
RAID1 для pg_xlog, остается раздел одного диска - для прочих целей.

Пока не выяснил, возможно ли и как реализуется наложение "чужеродного"
журнала транзакций на восстановленные базы нового кластера initdb?
Может придется отказаться от постоянного initdb в случае
форсмажора/RAM-диска.

Может идея этой стратегии бредовая, выложите, пожалуйста, свои
соображения и свои, может уже реализованные, стратегии по данной теме.

Спасибо.

--
---
С уважением,
Михаил Наседкин

Нормально должно реализовываться, есть раздел по данной стратегии в
документации ПГ "Continuous Archiving and Point-In-Time Recovery".
Только не через initdb при крахе как я сначала думал, а через
описанную в документации процедуры с использованием restore_command.

--
---
С уважением,
Михаил Наседкин

Да, конечно, дошел до документации.

Подумал, что оптимальнее будет схема бакапа:
- настроить архивирование журнала транзакций (archive_command)
- еженедельно запускать скрипт:
psql -c "select pg_start_backup('недельное резервирование');"
tar -cf /var/lib/pgsql/backup.tar /var/lib/pgsql/data/
psql -c "select pg_stop_backup();"

Т.е. возможен будет возврат к данным любого времени дней недели между
полными бакапами за счет файлов журнала транзакций.

Возникает вопрос: как очищать архивную директорию от уже не нужных
(более ранних) файлов транзакций, которые были до очередного полного
бакапа (tar), чтобы каталог не распух.

Кстати, не так давно, летом (июнь), на листе рассылки
pgsql-performance@postgresql.org была очень активная дискуссия на тему
"PostgreSQL as a local in-memory cache". Я не совсем там разобрался в
связи с трудностями перевода и вообще понимания сути вещей.

--
Михаил Наседкин


--
---
С уважением,
Михаил Наседкин

Ага, подсказали, спасибо.

--
Михаил Наседкин

--
---
С уважением,
Михаил Наседкин

И еще вопросы.

Каково значение команд pg_start_backup и pg_stop_backup? Без них
никак? Просто tar? Или это обязательные точки отсчета при процедуре
восстановления?
Не совсем понятна процедура считывания этих файлов, как сервер их
находит в куче файлов транзакций?

Есть пример, (http://www.mkyong.com/database/postgresql-point-in-time-recovery-incremental-backup/)
где автор статьи просто приводит выдержку из лога:
.....
cp: cannot stat `/usr/local/pgsql/pgbackup/wals/00000001.history': No
such file or directory
cp: cannot stat `/usr/local/pgsql/pgbackup/wals/00000001.history': No
such file or directory
LOG:  restored log file "000000010000000000000006.00BA9328.backup" from archive
LOG:  restored log file "000000010000000000000006" from archive
LOG:  automatic recovery in progress
LOG:  redo starts at 0/6BA9368
....
Т.е. типа "сначала не нашел по дефолту, зато нашел что-то еще и
определил точку отсчета".

--
Михаил Наседкин

--
---
С уважением,
Михаил Наседкин

Доброго.

На место RAID0 для быстродействия сейчас предлагается SSD.

--
---
С уважением,
Михаил Наседкин

Vladimir Rusinov wrote:
>
> 2010/11/16 Mihail Nasedkin <m.nasedkin@gmail.com
> <mailto:m.nasedkin@gmail.com>>
>
>     Возникает вопрос: как очищать архивную директорию от уже не нужных
>     (более ранних) файлов транзакций, которые были до очередного полного
>     бакапа (tar), чтобы каталог не распух.
>
>
> Я делаю так:
> бекап (tar) раз в неделю в $backup_dir/current/data/, wal пишется в
> $backup_dir/currept/xlog/
> Перед бекапом current переименовывается в previous, а струкрура
> директорий в current пересоздается.

а чем pg_dump  не подходит?

Vladimir Rusinov wrote:
>
>
> 2010/11/19 Sergej Kandyla <sk@hlsrv.com <mailto:sk@hlsrv.com>>
>
>     Vladimir Rusinov wrote:
>
>
>         2010/11/16 Mihail Nasedkin <m.nasedkin@gmail.com
>         <mailto:m.nasedkin@gmail.com> <mailto:m.nasedkin@gmail.com
>         <mailto:m.nasedkin@gmail.com>>>
>
>
>            Возникает вопрос: как очищать архивную директорию от уже не
>         нужных
>            (более ранних) файлов транзакций, которые были до
>         очередного полного
>            бакапа (tar), чтобы каталог не распух.
>
>
>         Я делаю так:
>         бекап (tar) раз в неделю в $backup_dir/current/data/, wal
>         пишется в $backup_dir/currept/xlog/
>         Перед бекапом current переименовывается в previous, а
>         струкрура директорий в current пересоздается.
>
>
>     а чем pg_dump  не подходит?
>
>
> Попробуйте сделать дамп базы в несколько хотя бы десятков Гб и вы
> поймете чем. Ну и возможность вернуться к любому состоянию минимум за
> неделю назад иногда очень помогает.
>
ну так я и спрашиваю, чтобы лучше понять )

Несколько десятков Гб, как бы и упаковываться архиватором будут не быстро.
Делать с живой базы нельзя - бекап будет не консистентным.

Или имеется ввиду уже архивировать данные со снапшота?

Доброго всем.

Возвращаюсь к основному руслу данной темы.

Думаю нужно дополнить тему по части оптимизации и настройке файловой
системы (ФС) под размещение в ней баз данных.
Я исхожу из ОС Линукс.
Допустим, я точно знаю, что конкретная база данных будет содержать
очень большие таблицы, а значит соответсвенно для PostgreSQL -
возникнут большие файлы.
Возникает вопрос: а может стоит отформатировать рабочий раздел с
особыми параметрами ФС.

Например, для ФС ext2 есть несколько опций, которые могут повлиять на
быстродействие файловых операций:
OPTIONS
    -b block-size - тут для больших разделов видимо автоматически встанет
максимальное значение - 4096 байта на блок.

    -E extended-options - вот тут уже интереснее:
        stride=stripe-size - для RAID можно указать колисчество блоков на
stripe. Мне пока не ясен этот параметр, нужно изучить тонкости RAID.

    -f fragment-size - тоже, возможно, интересный параметр. Пока не ясно
что выставлять.

    -g blocks-per-group - тоже параметр связанный с stripe RAID. Не ясно.

    -i bytes-per-inode - думаю важное отношение байты/узел, нужно
учитывать размер блока (block-size). В файле /etc/mke2fs.conf есть
указание для настроек (опция -T):
        largefile = {inode_ratio = 1048576}
        largefile4 = {inode_ratio = 4194304}

    -I inode-size - думаю интересная опция. Для современных ядер Линукса
можно указать кратно 128 байтов, допустим 256, но не известно (без
тестов), как это повлияет на производительность.

    -J journal-options - а что, может и опции журнала могут повлиять?
Вынести на другое устройство?

Кто-нибудь возьмется прокомментировать аспекты настройки файловых систем?


--
---
С уважением,
Михаил Наседкин

20.11.10, Vladimir Rusinov<vladimir@greenmice.info> написал(а):

> PS: сорри за офтоп в этой ветке

Все нормально.


--
---
С уважением,
Михаил Наседкин