Re: Performance monitoring
От | Joshua D. Drake |
---|---|
Тема | Re: Performance monitoring |
Дата | |
Msg-id | 464630EA.5000701@commandprompt.com обсуждение исходный текст |
Ответ на | Performance monitoring (was: [PATCHES] Logging checkpoints and other slowdown causes) ("Jim C. Nasby" <decibel@decibel.org>) |
Ответы |
Re: Performance monitoring
Re: Performance monitoring |
Список | pgsql-hackers |
> Not to beat a dead horse, but do we really want to force folks to be > parsing logs for performance monitoring? Especially if that log parsing > is just going to result in data being inserted into a table anyway? > > I know there's concern about performance of the stats system and maybe > that needs to be addressed, but pushing users to log parsing is a lot of > extra effort, non-standard, likely to be overlooked, and doesn't play > well with other tools. It also conflicts with all the existing > statistics framework. One thing that doesn't seemed to be being looked at it is the cost of logging. Logging is very expensive. I don't know if it is more expensive than the stats system, but you can cut your tps in half by having any level of verbose logging on. Yes that can be offset by pushing the logging to another spindle, and being careful about what you are logging but still. Either way, we are taking the hit, it is just a matter of where. IMO it would be better to have the information in the database where it makes sense, than pushing out to a log that: A. Will likely be forgotten B. Is only accessible if you have shell access to the machine (not as common as all of us would like to think) Sincerely, Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/
В списке pgsql-hackers по дате отправления: