Re: Redhat 7.2.93 performance (was:Re: [HACKERS] PostgreSQL 7.2.1-2PGDG RPMs available for RedHat-skipjack 7.2.93 and RedHat 6.2/SPARC)
On Sun, Apr 14, 2002 at 03:15:39PM -0400, Lamar Owen wrote: > ISTM that improving interactive performance would also improve multiuser > performance in a server, as low latency and kernel preemption can increase > multiuser server responsiveness. I doubt any performance will increase, either on a multiuser or on a singleuser system. Having faster response on mouse clicks or keyboard input doesn't translate on better overall performance, the user just has the felling that it's so. As an example, a part of those patches causes brakes in the middle of some loops (saving buffers to disk, etc). Then other applications that don't depend on disk activity can have change to run, so the system seems faster, it's more responsive. But it won't actually be faster, the system still has to lock again and continue saving the buffers. Actually, in this case there will be an overhead caused by checking if the kernel should brake. However, both projects review the Linux code, and may find, if they haven't already, some places were a finer locking may be used, giving a better performance in a SMP system. But it could also break some integrity. Those patches are not recomended for a server, and now I'm curious to check if the -enterprise configuration has them active. > Did you happen to report it to Red Hat's Skipjack list, or to > bugzilla.redhat.com/bugzilla? Helps make a better dist! Alas, a bug report saying: the system crashed, I can't login remotely, doesn't help a lot... Regards, Luciano Rocha -- Luciano Rocha, [EMAIL PROTECTED] The trouble with computers is that they do what you tell them, not what you want. -- D. Cohen ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: Redhat 7.2.93 performance (was:Re: [HACKERS] PostgreSQL 7.2.1-2PGDG RPMs available for RedHat-skipjack 7.2.93 and RedHat 6.2/SPARC)
Lamar Owen wrote: [EMAIL PROTECTED]"> The low-latency and preemptible patches are not meant for performancegains, but for responsiveness, and are not designed to be used in servers,only in workstations/desktops. ISTM that improving interactive performance would also improve multiuser performance in a server, as low latency and kernel preemption can increase multiuser server responsiveness. responsiveness != performance IT works OK for a low number of concurrent users/processes to increase percieved performance, but to get real gains on large systems with large numebrs of users and processes you actually decrease the responsiveness of individual tasks (IE make the system a little less likely to context switch or pre-empt) and schedual in batches or clusters rather than one-at-a-time. For a desktop/workstation this would be insane, and drive a user to kill someone, but for systems that handle several hundred users (interactive or not) this improves overall perfomance. 2.4.18 has a lot of work done to the VM, but most importantly has work done to the queue elevator code, thats probably whats doing most of the work (throttling big writers) of seeing better overall system performance.
Re: Redhat 7.2.93 performance (was:Re: [HACKERS] PostgreSQL 7.2.1-2PGDG RPMs available for RedHat-skipjack 7.2.93 and RedHat 6.2/SPARC)
On Sunday 14 April 2002 03:00 pm, Luciano Miguel Ferreira Rocha wrote: > On Sun, Apr 14, 2002 at 02:35:13PM -0400, Lamar Owen wrote: > > Raw performance seems to be increased as well, due to an improved kernel > > (2.4.18 plus low-latency and preemptible patches, according to the kernel > > source RPM). > The low-latency and preemptible patches are not meant for performance > gains, but for responsiveness, and are not designed to be used in servers, > only in workstations/desktops. ISTM that improving interactive performance would also improve multiuser performance in a server, as low latency and kernel preemption can increase multiuser server responsiveness. > > Although I am a little overwhelmed by the increased performance > > of this new Athlon 1.2+512MB RAM versus my old Celeron 650+192MB RAM, > > 7.2.93 seems to be faster on the same hardware. > 2.4.18 does come with a improved VM, what could justify the performance > increase. As could an update on the compiler (I've being using gcc 3.1 in > my redhat 7.2). The stock gcc on 7.2.93 is still the RedHat-branded 2.96, but with lots of fixes backported from higher versions. However, the improved VM may indeed be a large part of it. It sure feels faster. > But I can't recomend the beta to anyone, we had problems with one > dual pentium iii server, causing random corruption on > /usr/include/*.h and a lock up. Did you happen to report it to Red Hat's Skipjack list, or to bugzilla.redhat.com/bugzilla? Helps make a better dist! I have had less problems thus far with 7.2.93 than I ever did with 7.2. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: Redhat 7.2.93 performance (was:Re: [HACKERS] PostgreSQL 7.2.1-2PGDG RPMs available for RedHat-skipjack 7.2.93 and RedHat 6.2/SPARC)
On Sun, Apr 14, 2002 at 02:35:13PM -0400, Lamar Owen wrote: > > Hmmm. > > Raw performance seems to be increased as well, due to an improved kernel > (2.4.18 plus low-latency and preemptible patches, according to the kernel > source RPM). The low-latency and preemptible patches are not meant for performance gains, but for responsiveness, and are not designed to be used in servers, only in workstations/desktops. > Although I am a little overwhelmed by the increased performance > of this new Athlon 1.2+512MB RAM versus my old Celeron 650+192MB RAM, 7.2.93 > seems to be faster on the same hardware. 2.4.18 does come with a improved VM, what could justify the performance increase. As could an update on the compiler (I've being using gcc 3.1 in my redhat 7.2). But I can't recomend the beta to anyone, we had problems with one dual pentium iii server, causing random corruption on /usr/include/*.h and a lock up. Regards, Luciano Rocha -- Luciano Rocha, [EMAIL PROTECTED] The trouble with computers is that they do what you tell them, not what you want. -- D. Cohen ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html