Re: measuring lwlock-related latency spikes
От | Simon Riggs |
---|---|
Тема | Re: measuring lwlock-related latency spikes |
Дата | |
Msg-id | CA+U5nM+u=ojgJkqP4uB1Yrzz5eNvvgN4_8-gtRW-A3pezCJDtQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: measuring lwlock-related latency spikes (Greg Stark <stark@mit.edu>) |
Ответы |
Re: measuring lwlock-related latency spikes
|
Список | pgsql-hackers |
On Sun, Apr 1, 2012 at 11:12 PM, Greg Stark <stark@mit.edu> wrote: > On Sun, Apr 1, 2012 at 10:27 PM, Simon Riggs <simon@2ndquadrant.com> wrote: >> So lock starvation on the control lock would cause a long wait after >> each I/O, making it look like an I/O problem. > > Except that both of the locks involved in his smoking gun occur > *after* the control lock has already been acquired. The one that's > actually being blocked for a long time is in fact acquiring a shared > lock which the queue jumping couldn't be hurting. Not true, please refer to code at line 544, as I already indicated. My understanding of the instrumentation is that the lock acquired at line 526 will show as the blocker until we reach line 555, so anything in between could be responsible for the wait. (As long as there are multiple possibilities, I will remain convinced that the cause could be any of them.) -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: