Unix Technical Forum

Re: general PG network slowness (possible cure) (repost)

This is a discussion on Re: general PG network slowness (possible cure) (repost) within the Pgsql Performance forums, part of the PostgreSQL category; --> "Also sprach Kenneth Marshall:" > improvement from coalescing the packets. Good luck in your investigations. While I am recompiling ...


Go Back   Unix Technical Forum > Database Server Software > PostgreSQL > Pgsql Performance

FAQ Members List Calendar Search Today's Posts Mark Forums Read
  #1 (permalink)  
Old 04-19-2008, 10:52 AM
Peter T. Breuer
 
Posts: n/a
Default Re: general PG network slowness (possible cure) (repost)

"Also sprach Kenneth Marshall:"
> improvement from coalescing the packets. Good luck in your investigations.


While I am recompiling stuff, just some stats.

Typical network traffic analysis during the PG runs:

Total Packets Processed 493,499
Unicast 100.0% 493,417
Broadcast 0.0% 82
Multicast 0.0% 0
pktCast distribution chart
Shortest 42 bytes
Average Size 192 bytes
Longest 1,514 bytes
<= 64 bytes 0.0% 158
64 to 128 bytes 77.3% 381,532
129 to 256 bytes 6.8% 33,362
257 to 512 bytes 8.6% 42,535
513 to 1024 bytes 4.0% 19,577
1025 to 1518 bytes 3.3% 16,335

Typical application rusage stats:

time ./c -timeout 12000 -database postgresql://pebbles/d /tmp/tty_io..c
user system elapsed cpu
7.866u 6.038s 5:49.13 3.9% 0+0k 0+0io 0pf+0w

Those stats show the system lost in i/o. It's neither in kernel nor in
userspace. Presumably the other side plus networking was the holdup.

For comparison, against localhost via loopback ("fake" networking):

time ./c -timeout 12000 -database postgresql://localhost/d /tmp/tty_io..c
user system elapsed cpu
9.483u 5.321s 2:41.78 9.1% 0+0k 0+0io 0pf+0w

but in that case postmaster was doing about 54% cpu, so the overall
cpu for server + client is 63%.

I moved to a unix domain socket and postmaster alone went to 68%.


time ./c -timeout 12000 -database postgresql://unix/var/run/postgresql/d /tmp/tty_io..c
user system elapsed cpu
9.569u 3.698s 2:52.41 7.6% 0+0k 0+0io 0pf+0w

The elapsed time is not much different between unix and localhost. One can
see that there is some i/o holdup because the two threads ought to do 100%
between them if handover of info were costless. The difference (the system
was queiscent o/w apart from the monitoring software, which shows only a
fraction of a percent loading). There were no memory shortages and swap
was disabled for the test (both sides)

For comparison, running against gdbm straignt to disk

time ./c -timeout 12000 /tmp/tty_io..c
user system elapsed cpu
2.637u 0.735s 0:05.34 62.9% 0+0k 0+0io 0pf+0w

Through localhost:

time ./c -timeout 12000 -database gdbm://localhost/ptb/c /tmp/tty_io..c
user system elapsed cpu
2.746u 3.699s 0:16.00 40.1% 0+0k 0+0io 0pf+0w

(the server process was at 35% cpu, for 75% total).

Across the net:

time ./c -timeout 12000 -database gdbm://pebbles/ptb/c /tmp/tty_io..c
user system elapsed cpu
2.982u 4.430s 1:03.44 7.9% 0+0k 0+0io 0pf+0w

(the server was at 7% cpu)


Have to go shopping ....

Peter

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiFurl this Post!
Reply With Quote
Reply


Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On
Forum Jump


All times are GMT. The time now is 05:09 AM.


Powered by vBulletin® Version 3.6.5
Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.
Search Engine Optimization by vBSEO 3.2.0
www.UnixAdminTalk.com