Re: single task postgresql
От | Greg Copeland |
---|---|
Тема | Re: single task postgresql |
Дата | |
Msg-id | 1015441548.20266.182.camel@mouse.copelandconsulting.net обсуждение исходный текст |
Ответ на | single task postgresql (Oleg Bartunov <oleg@sai.msu.su>) |
Список | pgsql-hackers |
Seems I'm replying rather quickly but I thought I'd point out that I went back and started looking at the cygipc code again. I'm now starting to suspect that that the majority of the performance impact we are seeing has to do with the semaphore implementation versus the shared memory implementation. Basically, the version which is using local memory is not having to contend with a significant amount of semaphore negotiations while the shared memory version must contend with this issue each and every time memory is accessed. It's worth noting that based on what I've seen so far (pointing out that lots still need to be reviewed), the semaphore implementation on via the cygipc library is going to yield an absolute worse case semaphore performance on Win32 platforms. That is, of all the natve synchronization mechanisms available for Win32, the use of a generic Semaphore is going to deliver the worst performance whereby one would expect it to be perhaps an order of magnitude or slower than an ideal Win32 semaphore implementation. So, if you have the time, perhaps you can write some quick benchmarks on Win32. One which simply allocates a shared memory region and randomly reads and writes to it. Same thing for the shared/memory mapped file implementation. Next, create a multi-process implementation based on each of your previous two tests. In these test, try using the cygwin library, native Win32 Mutex implementation (warning, this has some issues because on Win32 Mutexs are optimized for threading and not multi-process implementations), a Win32 Critical section (warning SMP scaling issues -- absolute fastest for uni-processor systems on Win32) and a native Win32 Semaphore implementation (horrible performance). Of course, timing each. If my *guess* is correct, this will tell you that the significant performance issues are directly associated with the use of Semaphores. As I am starting to understand things, it looks like performance suffers because the Win32 platforms are significantly biased toward threaded IPC implementations and significantly suffer when forced into a multi-process architecture (very Unix like). Greg On Wed, 2002-03-06 at 09:36, Oleg Bartunov wrote: > Mark, > > I've found > "Fast synchronized access to shared memory for Windows and for i86 Unix-es" > http://www.ispras.ru/~knizhnik/shmem/Readme.htm > Would't be useful ? > > > Regards, > > Oleg > > > On Wed, 27 Feb 2002, mlw wrote: > > > Oleg Bartunov wrote: > > > > > > On Wed, 27 Feb 2002, mlw wrote: > > > > > > > Greg Copeland wrote: > > > > > > > > > > Windows does not really have shared memory support. This has been a > > > > > beef with the Win32 API for a long time now. Because it has been a long > > > > > time complaint, it was finally added in Win2000 and later. Likewise, > > > > > I'd like to point out that thinks like sims, shared memory, pipes, etc, > > > > > and other entities commonly used for concurrent programming strategies > > > > > are slower in XP. So, because shared memory really isn't well > > > > > supported, they elected to have what is, in essense, memory mapped > > > > > files. Multiple processes then map the same file and read/write to it > > > > > as needed, more or less as you would shared memory. Unless you plan on > > > > > only targetting on Win 2000 and XP, it sounds like a waste of time. > > > > > > > > This is not really true. Under DOS windows, i.e. 95,98, etc. Shared memory can > > > > be done in 16 bit land with a touch of assembly and a DLL. Allocate, with > > > > globalalloc, a shared memory segment. The base selector is a valid 32 bit > > > > selector, and the memory is mapped in the above 2G space shared and mapped to > > > > all 32bit processes. > > > > > > > > Under NT through 2K, yes using a memory mapped files is the way to do it, but > > > > you do not actually need to create a file, you can use (HANDLE)0xFFFFFFFF, > > > > which is the NT equivilent of the system memory file. The handle returned is a > > > > system global object which can be shared across processes. > > > > > > > > > > Mark, > > > > > > do you consider to work on this issue ? > > > > Yea, let me think about it. What is your time frame? When I offered to work on > > it, I thought it could be a leasurely thing. I have to get a machine running > > some form of Windows on which to develop and test. > > > > I want to say yes, and if no one else does it, I will, but I'm not sure what > > your timeframe is. If it is the mystical 7.3, then sure I can do it easily. If > > you need something quickly, I can help, but I don't think I could shoulder the > > whole thing. > > > > I have a couple things I have promised people. Let me get those done. I will > > try to write an equivilent set of functions for shget, shmat, etc. as soon as I > > can. Anyone wanting to run with them can hack and test PostgreSQL on Windows. > > > > How does that sound? > > > > Regards, > Oleg > _____________________________________________________________ > Oleg Bartunov, sci.researcher, hostmaster of AstroNet, > Sternberg Astronomical Institute, Moscow University (Russia) > Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/ > phone: +007(095)939-16-83, +007(095)939-23-83 >
В списке pgsql-hackers по дате отправления:
Предыдущее
От: Bruce MomjianДата:
Сообщение: Re: Postgresql backend to perform vacuum automatically