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

["Eugene Prokopiev" <enp@altlinux.org>]

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

А причем тут именно SATA? Ну а данных, как я выше сказал, не жалко ...

> > 2) данные на одном диске, логи на другом - но логи занимают
> > значительно меньше места, чем данные - а места жалко
> > 3) данные на одном диске, индексы на другом - куда тогда девать логи?
> > размазывать по двум дискам в виде RAID0?
> >
> > Если делать то же на трех дисках, то на третий лучше выносить
> > логи постгреса и логи XFS одновременно?
>
> Вот тут экспериментируй, но вполне может быть.  Я бы ещё на
> WD Raptor тогда посмотрел (пока себе раскачивался взять --
> пробежали 15kRPM SAS).

Про то, что там стоит, dmesg говорит WDC WD2500KS-00M. Не годится?

С логами и третьим диском такой еще вопрос: логи XFS - это как я
понимаю, отдельный раздел, логи простгреса - тоже раздел, но уже с ФС,
а куда складывать логи этой ФС? ;)

Кстати, я правильно понимаю, что вынесение любых логов (ФС, БД) на
отдельный диск увеличивает скорость записи, а на скорость чтения
особого влияния не оказывает? Мне-то именно скорость чтения критична.

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

Так мы же вроде в sysadmins@ или нет?

-- 
С уважением,
Прокопьев Евгений