Skip site navigation (1) Skip section navigation (2)

Оптимизация на уровне ОС.

From: Mihail Nasedkin <m(dot)nasedkin(at)gmail(dot)com>
To: pgsql-ru-general(at)postgresql(dot)org
Subject: Оптимизация на уровне ОС.
Date: 2010-11-16 03:37:33
Message-ID: AANLkTimu3s5a6Vs2TVf-UwkChVUnzeQ7Df5d9C5o82Wf@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-ru-general
Здравствуйте, сообщество 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-диска.

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

Спасибо.

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

Responses

pgsql-ru-general by date

Next:From: Mihail NasedkinDate: 2010-11-16 08:51:52
Subject: Re: Оптимизация на уровне ОС.
Previous:From: Mihail NasedkinDate: 2010-10-29 13:34:50
Subject: Re: [pgsql-ru-general] Re: [pgsql-ru-general] Re: [p

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group