Re: User concurrency thresholding: where do I look?
От | Jignesh K. Shah |
---|---|
Тема | Re: User concurrency thresholding: where do I look? |
Дата | |
Msg-id | 46A1205B.8010205@sun.com обсуждение исходный текст |
Ответ на | Re: User concurrency thresholding: where do I look? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: User concurrency thresholding: where do I look?
|
Список | pgsql-performance |
sorry.. The are solaris mutex locks used by the postgresql process. What its saying is that there are holds/waits in trying to get locks which are locked at Solaris user library levels called from the postgresql functions: For example both the following functions are hitting on the same mutex lock 0x10059e280 in Solaris Library call: postgres`AllocSetDelete+0x98 postgres`AllocSetAlloc+0x1c4 I need to enable the DTrace probes on my builds -Jignesh Tom Lane wrote: > "Jignesh K. Shah" <J.K.Shah@Sun.COM> writes: > >> Tom Lane wrote: >> >>> So follow that up --- try to determine which lock is being contended >>> for. There's some very crude code in the sources that you can enable >>> with -DLWLOCK_STATS, but probably DTrace would be a better tool. >>> > > >> Using plockstat -A -s 5 -p $pid >> > > I don't know what that is, but it doesn't appear to have anything to do > with Postgres LWLocks or spinlocks, which are the locks I was thinking of. > Try asking Robert Lor about this --- IIRC he had some dtrace probes to > work with our locks. > > regards, tom lane >
В списке pgsql-performance по дате отправления: