Re: NAS, SAN or any alternate solution ?

Поиск
Список
Период
Сортировка
От Andrew Hammond
Тема Re: NAS, SAN or any alternate solution ?
Дата
Msg-id 4151E1E7.2000009@ca.afilias.info
обсуждение исходный текст
Ответ на Re: NAS, SAN or any alternate solution ?  (Rod Taylor <pg@rbt.ca>)
Ответы Re: NAS, SAN or any alternate solution ?
Re: NAS, SAN or any alternate solution ?
Список pgsql-performance
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Rod Taylor wrote:
| I've used both a NetApp and Hitachi based SANs with PostgreSQL. Both
| work as well as expected, but do require some tweeking as they normally
| are not optimized for the datablock size that PostgreSQL likes to deal
| with (8k by default) -- this can make as much as a 50% difference in
| performance levels.

I'm looking for documentation about the datablock size you mentioned above.

My goal is to tune the disk / filesystem on our prototype system. It's
an EMC disk array, so sectors on disk are 512 bytes of usable space.
We've decided to go with RAID 10 since the goal is to maximize
performance. Currently the raid element size is set at 16 sectors which
is 8192 bytes of payload. I've got a sysadmin working on getting XFS
going with 8192 byte blocks. My next task will be to calculate the
amount of space used by XFS for headers etc. to find out how much of
those 8192 bytes can be used for the postgres payload. Then configure
postgres to use datablocks that size. So I'm looking for details on how
to manipulate the size of the datablock.

I'm also not entirely sure how to make the datablocks line up with the
filesystem blocks. Any suggestions on this would be greatly appreciated.

- --
Andrew Hammond    416-673-4138    ahammond@ca.afilias.info
Database Administrator, Afilias Canada Corp.
CB83 2838 4B67 D40F D086 3568 81FC E7E5 27AF 4A9A
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQFBUeHmgfzn5SevSpoRAu2sAJ4nHHup5lhp4+RcgBPGoJpUFoE1SQCgyvW1
ixyAvqb7ZkB+IIdGb36mpxI=
=uDLW
-----END PGP SIGNATURE-----

В списке pgsql-performance по дате отправления:

Предыдущее
От: Steven Rosenstein
Дата:
Сообщение: Infinite CPU loop due to field ::type casting
Следующее
От: Steven Rosenstein
Дата:
Сообщение: Fw: Infinite CPU loop due to field ::type casting, Take II :-)