Re: postgresql meltdown on PlanetMath.org
От | Sean Chittenden |
---|---|
Тема | Re: postgresql meltdown on PlanetMath.org |
Дата | |
Msg-id | 20030316082024.GA66903@perrin.int.nxad.com обсуждение исходный текст |
Ответ на | Re: postgresql meltdown on PlanetMath.org (Aaron Krowne <akrowne@vt.edu>) |
Ответы |
Re: postgresql meltdown on PlanetMath.org
|
Список | pgsql-performance |
> > > - Lastly, I tried reducing the shared memory max and limiting postgresql > > > to more conservative values, although still not to the out-of-box > > > values. Right now shared memory max on the system is 128mb, > > > postgres's shared buffers are at 64mb, sort_mem is at 16mb, and > > > effective cache size is at 10mb. > > *) You shouldn't have to do this either. > > Well, I've now been advised that the best way is all 3 that I have > tried (among aggressive buffering, moderate buffering, and default > conservative buffering). > > Perhaps you could explain to me why the system shouldn't be ok with > the moderate set of buffer sizes on a 512mb machine? I don't really > know enough about the internals of postgres to be doing anything but > voodoo when I change the values. Honestly? The defaults are small, but they're not small enough to give you the lousy performance you were describing. If your buffers are too high or there are enough things that are using up KVM/system memory... contention can cause thashing/swapping which it wasn't clear that you weren't having happen. Defaults shouldn't, under any non-embedded circumstance cause problems with machines >233Mhz, they're just too conservative to do any harm. :) > > *) Have you done a vacuum analyze? > > See previous message to list (summary: it worked this time, but > usually it does not help.) Hrmm... ENOTFREEBSD, eh? http://www.freebsd.org/cgi/cvsweb.cgi/ports/databases/postgresql7/files/502.pgsql?rev=1.5&content-type=text/x-cvsweb-markup You may want to setup a nightly vacuum/backup procedure. Palle Girgensohn <girgen@pingpong.net> has written a really nice and simple script that's been in use for ages on FreeBSD PostgreSQL installations for making sure that you don't have this problem. Actually, it'd be really cool to lobby to get this script added to the base PostgreSQL installation that way you wouldn't have this problem... it'd also dramatically increase the number of nightly backups performed for folks if a default script does this along with vacuuming. -sc -- Sean Chittenden
В списке pgsql-performance по дате отправления: