Re: First set of OSDL Shared Mem scalability results, some
От | Alan Stange |
---|---|
Тема | Re: First set of OSDL Shared Mem scalability results, some |
Дата | |
Msg-id | 416FC83F.3020900@rentec.com обсуждение исходный текст |
Ответ на | Re: First set of OSDL Shared Mem scalability results, some wierdness ... (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-performance |
Tom Lane wrote: >Kevin Brown <kevin@sysexperts.com> writes: > > >>Hmm...something just occurred to me about this. >> >> >>Would a hybrid approach be possible? That is, use mmap() to handle >>reads, and use write() to handle writes? >> >> > >Nope. Have you read the specs regarding mmap-vs-stdio synchronization? >Basically it says that there are no guarantees whatsoever if you try >this. The SUS text is a bit weaselly ("the application must ensure >correct synchronization") but the HPUX mmap man page, among others, >lays it on the line: > > It is also unspecified whether write references to a memory region > mapped with MAP_SHARED are visible to processes reading the file and > whether writes to a file are visible to processes that have mapped the > modified portion of that file, except for the effect of msync(). > >It might work on particular OSes but I think depending on such behavior >would be folly... > We have some anecdotal experience along these lines: There was a set of kernel bugs in Solaris 2.6 or 7 related to this as well. We had several kernel panics and it took a bit to chase down, but the basic feedback was "oops. we're screwed". I've forgotten most of the details right now; the basic problem was a file was being read+written via mmap and read()/write() at (essentially) the same time from the same pid. It would panic the system quite reliably. I believe the bugs related to this have been resolved in Solaris, but it was unpleasant to chase that problem down... -- Alan
В списке pgsql-performance по дате отправления: