Re: Hope for a new PostgreSQL era?
От | Satoshi Nagayasu |
---|---|
Тема | Re: Hope for a new PostgreSQL era? |
Дата | |
Msg-id | 4EE5461A.3010208@gmail.com обсуждение исходный текст |
Ответ на | Re: Hope for a new PostgreSQL era? (Greg Smith <greg@2ndQuadrant.com>) |
Ответы |
Re: Hope for a new PostgreSQL era?
|
Список | pgsql-general |
2011/12/10 10:54, Greg Smith wrote: > On 12/08/2011 09:48 AM, Satoshi Nagayasu wrote: >> For examples, I've been working on investigating PostgreSQL LWLock behaviors >> precisely for a few weeks, and it could not be obtained within PostgreSQL >> itself, therefore, I picked up SystemTap. However, SystemTap could not be >> used in a production system, because it often kills the target processes. :( >> How can I observe LWLocks in the production system? > > I decided about a year ago that further work on using SystemTap was a black hole: time goes in, nothing really usable onany production server seems to come out. It can be useful for collecting data in a developer context. But the sort of problemspeople are more interested in all involve "why is the production server doing this?", and as you've also discoveredthe only reasonable answer so far doesn't involve SystemTap; it involves DTrace and either Solaris or FreeBSD (orMac OS, for smaller server hardware deployments). Since those platforms are problematic to run database servers on inmany cases, that doesn't help very much. Absolutely. SystemTap would be useful if I'm able to reproduce the situation outside the production system. However, in most cases, it would be actually difficult. > I'm planning to put that instrumentation into the database directly, which is what people with Oracle background are askingfor. There are two underlying low-level problems to solve before even starting that: > > -How can the overhead of collecting the timing data be kept down? It's really high in some places. This is being workedout right now on pgsql-hackers, see "Timing overhead and Linux clock sources" > > -How do you log the potentially large amount of data collected without killing server performance? Initial discussionsalso happening right now, see "logging in high performance systems". > > I feel this will increasingly be the top blocker for performance sensitive deployments in the coming year, people usedto having these tools in Oracle cannot imagine how they would operate without them. One of my big pictures goals is havethis available as a compile-time option starting in PostgreSQL 9.3 in 2013, piggybacked off the existing DTrace support.And the earlier the better--since many migrations have a long lead time, just knowing it's coming in the next versionwould be good enough for some people who are blocked right now to start working on theirs. I'm glad to hear that. I'm very interested in focusing on it, and will follow the threads. Thanks. -- NAGAYASU Satoshi <satoshi.nagayasu@gmail.com>
В списке pgsql-general по дате отправления: