Re: beta3 Solaris 7 (SPARC) port report
От | Ross J. Reedstrom |
---|---|
Тема | Re: beta3 Solaris 7 (SPARC) port report |
Дата | |
Msg-id | 20010126103611.A22226@rice.edu обсуждение исходный текст |
Ответ на | Re: beta3 Solaris 7 (SPARC) port report (Frank Joerdens <frank@joerdens.de>) |
Ответы |
Re: beta3 Solaris 7 (SPARC) port report
Re: beta3 Solaris 7 (SPARC) port report |
Список | pgsql-hackers |
On Fri, Jan 26, 2001 at 05:03:13PM +0100, Frank Joerdens wrote: > > There is no load at all on this server at the moment. The sysadmin and > myself are currently the only people accessing a brand new UltraSPARC with 3 > CPUs and 3/4 GB of RAM to install stuff. Hmm, multiple processors, and lots of IPC: I've got a bad feeling about this. Nothing solid (don't do a lot with Solaris), but there are a _lot_ of gotchas in getting that combo right, many of which _kill_ performance for the normal case to get correct behavior in an edge case. I could imagine Sun missing one or two, and not catching it (or actively ignoring it, to get better CPU utilization) Since it seems to hit only when using Unix domain sockets, I'd take a wild guess that explicit use of shared memory and Unix domain sockets are stepping on each other in a multiprocessor environment. Invoking Inet sockets gets more of the networking code in play, which is usually more heavily tested in such an environment. Since it's just you and the sysadmin: any chance you could bring the system up uniprocessor (I don't even know if this is _possible_ with Sun hardware, let alone how hard) and run the regressions some more? If that makes it go away, I'd say it pretty well points straight into the Solaris kernel. Ross -- Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu> NSBRI Research Scientist/Programmer Computer and Information Technology Institute Rice University, 6100 S. Main St., Houston, TX 77005
В списке pgsql-hackers по дате отправления: