Re: [Sysadmins] оптимизация дисковой подсистемы (linux multi-disk server howto) (was: OpenVZ, VServer и полудесяток)

["Денис Смирнов" <mithraen@altlinux.ru>]

[-- Attachment #1: Type: text/plain, Size: 3684 bytes --]

On Tue, Dec 25, 2007 at 06:51:51PM +0300, Eugene Prokopiev wrote:

>> На всякий случай напоминаю любителям пораскидывать все по разным
>> шпинделям о tablespaces в постгресе. Раскидывать отдельные таблички по
>> разным шпинделям может быть ой как полезно.
EP> А раскидывать отдельно данные и индексы?

Разумеется тоже полезно :)
Кстати я об этом почему-то не задумывался, а результат-то достигается
элементарно и, как мне кажется, во многих случаях существенный...

EP> Есть у меня железка, в которую можно воткнуть не более 2-х
EP> SATA-дисков, и требуется поднять на ней постгрес. Сама система вместе
EP> со всеми скриптами ценнее, чем данные, которые лежат еще и в сейфе на
EP> DVD-R и которые можно залить повторно, но желательно в БД держать как
EP> можно больше данных и делать выборки из них как можно быстрее.
EP> Соотвественно, систему планируется держать на RAID1, а вот данные
EP> непонятно. Т.е. альтернативы XFS нет, а вот что ниже? Варианты:

Для БД ext3 с data=journal работает очень даже замечательно. Я не пробовал
проводить тестирование что реально лучше.

EP> 2) данные на одном диске, логи на другом - но логи занимают
EP> значительно меньше места, чем данные - а места жалко

У тебя два диска. Раскидвай данные по ним так, чтобы нагрузка была
более-менее равномерная. То есть логи да, на один. Можно еще что-то на
него же.

Логи, кстати, лучше всего действительно на XFS.

EP> 3) данные на одном диске, индексы на другом - куда тогда девать логи?
EP> размазывать по двум дискам в виде RAID0?

Нафиг-нафиг! RAID0, кстати, чтобы давал ускорение а не тормоза еще тюнить
надо. Для логов у меня есть сомнения в пользе такого действия.

EP> Если делать то же на трех дисках, то на третий лучше выносить логи
EP> постгреса и логи XFS одновременно?

Хороший вопрос. Я не знаю на него ответа, к сожалению.

>> Жаль в постгресе до сих пор нельзя делать индексы сразу по всем
>> наследникам конкретной таблицы (необходимо для unique значений), когда
>> это появится, будет вообще чудесная возможность практически не трогая
>> frontend выкидывать редко используемые _отдельные row_ на другой
>> шпиндель.
EP> Можно чуть подробнее: как формулируется задача и что хочется получить?

Краткая вводная:
В постгресе есть зачатки объектно-ориентированности. В том числе
"наследование".

Так вот, к примеру, можно сделать табличку:
CREATE TABLE blabla (
	blabla_id	SERIAL PRIMARY KEY,
	cooldata VARCHAR,
	is_old	BOOLEAN NOT NULL
	CHECK(is_old == 'f')
);

CREATE TABLE blabla_old LIKE blabla(
	CHECK(is_old == 't')
);

Реально создалось две таблицы. Самое интересное в этом то, что если мы
заполним их данными, а дальше выполним команду:

SELECT * FROM blabla*;
то мы получим данные из обеих (!) таблиц.

А если:

SELECT * FROM blabla* WHERE is_old = 'f';

То никаких обращений к второй таблице не будет вообще.

Собственно описание достаточно краткое, там надо еще чуточку с бубном
поплясать чтобы это заработало, но потенциал у этого решения огромный.

А вот засада следующая -- blabla_id не уникален для этой группы таблиц, он
уникален только в пределах одной таблицы. При этом благодаря тому что он
SERIAL он при заполнении будет вроде как казаться уникальным (на все
таблицы будет одна sequence), но insert/update с указанием конкретного
значения для blabla_id эту идиллию разрушат.

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

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
Старый глюк лучше новых двух.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]