Re: intel vs amd benchmark for pg server part 2
От | Lincoln Yeoh |
---|---|
Тема | Re: intel vs amd benchmark for pg server part 2 |
Дата | |
Msg-id | 5.1.0.14.1.20020427174138.02a7ecf0@192.228.128.13 обсуждение исходный текст |
Ответ на | intel vs amd benchmark for pg server part 2 (postgres@vrane.com) |
Список | pgsql-general |
Erm. I think you've missed the point slightly. All that CPU power is so that you can watch movies and play MP3s whilst waiting for VACUUM to finish[1]. Be sure to have your movie files on another disk and I/O channel, so that frames don't get lost - but of course ;). Note: if you really don't need the CPU power, what you could do is underclock your CPU, that way you can run cooler and more reliably (maybe even go fanless) or you can get someone else to do it for you and buy a Celeron. Hope that helps, Link. [1] When you are vacuuming really large databases you might even want to crack crypto whilst you're at it :). Or do some ray tracing, or machinima/animated films. Of course with the advances of Postgresql 7.2 these times of repose and reflection will become briefer, rarer and more precious. How we will miss glimpses of The Boss yelling and hammering on the locked server room door whilst the vacuum is going on. But take heart, for the Benevolent Developers in their great wisdom and grace hath provided VACUUM FULL, and our disk buffers overfloweth with joy. At 10:52 PM 4/26/02 -0400, postgres@vrane.com wrote: >The moral I get from this benchmark is that AMD is certainly >not much better preformance/price wise at least not for >a database server > >In fact for various reasons I am going to go with an intel >box. > >Another gripe I have is that vacuum process does not eat up 100% >of cpu. In the beginning it peaks around 80% and at the end >it is stuck around 20%. > >Whenever I have a long running process and >it is not eating up 100% of cpu I feel I am not getting my money's >worth for the cpu. I wonder why vacuum process is not more parallelized >if at all. I can imagine manually vacuuming many tables in parallel >and it might eat up all cpu and I wonder whether it might finish quicker.
В списке pgsql-general по дате отправления: