Re: High-CPU consumption on information_schema (only) query
От | Jeff Janes |
---|---|
Тема | Re: High-CPU consumption on information_schema (only) query |
Дата | |
Msg-id | CAMkU=1ynPaPxL3TcoWQxub25SuQ9MyYLY_BazYYegv3HsxXj1g@mail.gmail.com обсуждение исходный текст |
Ответ на | High-CPU consumption on information_schema (only) query (Robins Tharakan <tharakan@gmail.com>) |
Список | pgsql-hackers |
<p dir="ltr">On Wed, Sep 7, 2016 at 4:37 PM, Robins Tharakan <<a href="mailto:tharakan@gmail.com">tharakan@gmail.com</a>>wrote:<br /><blockquote><p dir="ltr">><br /></blockquote><pdir="ltr">> Hi,<br /> ><br /> > An SQL (with only information_schema related JOINS) when triggered,runs with max CPU (and never ends - killed after 2 days).<br /> > - It runs similarly (very slow) on a replicatedserver that acts as a read-only slave.<br /> > - Top shows only postgres as hitting max CPU (nothing else).When query killed, CPU near 0%.<br /> > - When the DB is restored on a separate test server (with the exact postgresql.conf)the same query works fine.<br /> > - There is no concurrent usage on the replicated / test server (althoughthe primary is a Production server and has concurrent users).<br /> ><br /> > Questions:<br />> - If this was a postgres bug or a configuration issue, query on the restored DB should have been slow too. Is theresomething very basic I am missing here?<br /> ><br /> > If someone asks for I could provide SQL + EXPLAIN, butit feels irrelevant here. I amn't looking for a specific solution but what else should I be looking for here? <br /><pdir="ltr">strace -ttt -T -y the process to see what system calls it is making. If it is not doing many systme calls,or they are uninformative, then attach the gdb debugger to it and periodically interrupt the process (ctrl c) and takea back trace (bt), then restart it (c) and repeat. If all the stack traces look similar, you will know where the timeis going. <br /> <br /> Cheers, <p dir="ltr">Jeff<br />
В списке pgsql-hackers по дате отправления: