From: nobody nowhere <devnull@mail.ua>
To: Claudio Freire <klaussfreire@gmail.com>
Cc: postgres performance list <pgsql-performance@postgresql.org>
Subject: Re[2]: [PERFORM] Re[2]: [PERFORM] SMP on a heavy loaded database
Date: Sat, 05 Jan 2013 12:37:49 +0400
Message-ID: <1357375069.89368168@f237.mail.ru> (raw)
In-Reply-To: <CAGTBQpZkk38g_Mk-V5BqB9vNqX0EobzAFBZ7i8rSR8Rj0U-bKA@mail.gmail.com>
References: <1357256708.822075673@f352.mail.ru>
<1357335491.318183949@f267.mail.ru>
<CAGTBQpZkk38g_Mk-V5BqB9vNqX0EobzAFBZ7i8rSR8Rj0U-bKA@mail.gmail.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-performance>
Пятница, 4 января 2013, 18:53 -03:00 от Claudio Freire <klaussfreire@gmail.com>:
>On Fri, Jan 4, 2013 at 6:38 PM, nobody nowhere < devnull@mail.ua > wrote:
>> On Fri, Jan 4, 2013 at 6:07 PM, nobody nowhere < devnull@mail.ua > wrote:
>>> 9092 postgres 16 0 4326m 41m 34m S 0.0 0.3 0:00.27 14 postgres: user
>>> user_db [local] idle
>>> 9098 postgres 16 0 4329m 203m 194m S 3.5 1.3 0:00.65 14 postgres: user
>>> user_db [local] idle
>>> 9099 postgres 16 0 4327m 45m 38m S 0.0 0.3 0:00.41 14 postgres: user
>>> user_db [local] idle
>>
>> That looks like pg has been pinned to CPU14. I don't think it's pg's
>> doing. All I can think of is: check scheduler tweaks, numa, and pg's
>> initscript. Just in case it's being pinned explicitly.
>>
>> Not pinned.
>> Forks with tcp connection use other CPU. I just add connections pool and
>> change socket to tcp
>
>How interesting. It must be a peculiarity of unix sockets. I know unix
>sockets have close to no buffering, task-switching to the consumer
>instead of buffering. Perhaps what you're experiencing here is this
>"optimization" effect. It's probably not harmful at all. The OS will
>switch to another CPU if the need arises. It's not socket problem.
Ths same result when I change php fast-cgi connection to tcp,
Remote clients over tcp use insert-delete. Just data collection. Nothing more.
Locally php its lot of PL data processing functions. It's PL problem !!
>
>
>Have you done any stress testing? Is there any actual performance impact?
On my experience stress testing and real production perfomance usually absolutely different. :)
No application development going together with business growing. We just add functional to the system step by step.
For a last couple month we just grow up quickly and I decide to check performance :(
>
>
>--
>Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
>To make changes to your subscription:
>http://www.postgresql.org/mailpref/pgsql-performance
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: devnull@mail.ua, klaussfreire@gmail.com
Subject: Re: Re[2]: [PERFORM] Re[2]: [PERFORM] SMP on a heavy loaded database
In-Reply-To: <1357375069.89368168@f237.mail.ru>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox