Re: Scaling with memory & disk planning (was Re: Non-linear
От | Curt Sampson |
---|---|
Тема | Re: Scaling with memory & disk planning (was Re: Non-linear |
Дата | |
Msg-id | Pine.NEB.4.43.0205311651500.448-100000@angelic.cynic.net обсуждение исходный текст |
Ответ на | Scaling with memory & disk planning (was Re: Non-linear Performance) (Doug Fields <dfields-pg-general@pexicom.com>) |
Список | pgsql-general |
On Thu, 30 May 2002, Doug Fields wrote: > If I ran PostgreSQL with a Linux 2.4 kernel and 6GB of RAM with dual P4 Xeons: > a) Could PostgreSQL use all the RAM? Yes, but no single process could. Since you're on a 32-bit machine your maximum address space is 4 GB, and the Linux kernel keeps 1 GB of that for itself, so no process (i.e., no individual backend, in this case) can address more than 3 GB of RAM. I'm not sure how the Linux buffer caching works, but there is a possibility that this kind of thing could give you a very nice large buffer cache. > c) Could PostgreSQL use this "hyperthreading" that apparently is in these > P4 Xeons making dual processors look like four processors (obviously, on > four separate queries)? Does Linux come up saying there are 4 processors installed in your system? If so, yes. If not, no. > d) How much extra performance does having the log or indices on a different > disk buy you, esp. in the instance where you are inserting millions of > records into a table? An indexed table? When inserting, log on a separate disk buys you a lot. (You don't get the table and index writes moving the disk head away from the end of the log file.) Splitting index and table files may help somewhat, but that's harder to determine. You always want to throw at them as many disk arms as you can, but it's usually the safer bet to combine it all on one big stripe set or raid or whatever, unless you have a very consistent workload and are willing to play around a lot to determine how you can best optimize this stuff. cjs -- Curt Sampson <cjs@cynic.net> +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're all light. --XTC
В списке pgsql-general по дате отправления: