From: Gerhard Wohlgenannt <wohlg@ai.wu.ac.at>
To: pgsql-performance@postgresql.org
Cc: Heinz-Peter Lang <heinz@langatium.net>
Cc: Gerhard Wohlgenannt <wohlg@ai.wu-wien.ac.at>
Cc: Weichselbraun, Albert <Albert.Weichselbraun@wu.ac.at>
Subject: Sudden drop in DBb performance
Date: Sat, 03 Sep 2011 09:26:44 +0200
Message-ID: <4E61D6B4.9090804@ai.wu.ac.at> (raw)
Dear list,
we are encountering serious performance problems with our database.
Queries which took around 100ms or less last week now take several seconds.
The database runs on Ubuntu Server 10.4.3 (kernel: 2.6.32-33) on
hardware as follows:
8-core Intel Xeon CPU with 2.83GHz
48 GB RAM
RAID 5 with 8 SAS disks
PostgreSQL 8.4.8 (installed from the Ubuntu repository).
Additionally to the DB the machine also hosts a few virtual machines. In
the past everything worked very well and the described problem occurs
just out of the blue. We don't know of any postgresql config changes or
anything else which might explain the performance reduction.
We have a number of DBs running in the cluster, and the problem seems to
affect all of them.
We checked the performance of the RAID .. which is reasonable for eg.
"hdparm -tT". Memory is well used, but not swapping.
vmstat shows, that the machine isn't using the swap and the load
shouldn't be also to high:
root@host:~# vmstat
procs -----------memory---------- ---swap-- -----io---- -system--
----cpu----
r b swpd free buff cache si so bi bo in cs us
sy id wa
0 0 0 308024 884812 40512932 0 0 464 168 353 92
4 2 84 9
Bonnie++ results given below, I am no expert at interpreting those :-)
Activating log_min_duration shows for instance this query --- there are
now constantly queries which take absurdely long.
2011-09-02 22:38:18 CEST LOG: Dauer: 25520.374 ms Anweisung: SELECT
keyword_id FROM keywords.table_x WHERE keyword=E'diplomaten'
db=# explain analyze SELECT keyword_id FROM keywords.table_x WHERE
keyword=E'diplomaten';
QUERY PLAN
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Index Scan using idx_table_x_keyword on table_x (cost=0.00..8.29
rows=1 width=4) (actual time=0.039..0.041 rows=1 loops=1)
Index Cond: ((keyword)::text = 'diplomaten'::text)
Total runtime: 0.087 ms
(3 Zeilen)
db=# \d keywords.table_x
Tabelle »keywords.table_x«
Spalte | Typ
| Attribute
------------+-------------------+------------------------------------------------------------------------------------------------------
keyword_id | integer | not null Vorgabewert
nextval('keywords.table_x_keyword_id_seq'::regclass)
keyword | character varying |
so | double precision |
Indexe:
"table_x_pkey" PRIMARY KEY, btree (keyword_id) CLUSTER
"idx_table_x_keyword" btree (keyword)
Fremdschlüsselverweise von:
TABLE "keywords.table_x_has" CONSTRAINT
"table_x_has_keyword_id_fkey" FOREIGN KEY (keyword_id) REFERENCES
keywords.table_x(keyword_id) ON UPDATE CASCADE ON DELETE CASCADE
Could you be so kind and give us any advice how to track down the
problem or comment on possible reasons???
Thank you very much in advance!!!
Regards,
heinz + gerhard
name
| current_setting
----------------------------+-------------------------------------------------------------------------------------------------------------
version | PostgreSQL 8.4.8 on x86_64-pc-linux-gnu,
compiled by GCC gcc-4.4.real (Ubuntu 4.4.3-4ubuntu5) 4.4.3, 64-bit
archive_command | /usr/local/sbin/weblyzard-wal-archiver.sh
%p %f
archive_mode | on
checkpoint_segments | 192
effective_cache_size | 25000MB
external_pid_file | /var/run/postgresql/8.4-main.pid
full_page_writes | on
geqo | on
lc_collate | de_AT.UTF-8
lc_ctype | de_AT.UTF-8
listen_addresses | *
log_line_prefix | %t
log_min_duration_statement | 3s
maintenance_work_mem | 500MB
max_connections | 250
max_stack_depth | 2MB
port | 5432
server_encoding | UTF8
shared_buffers | 7000MB
ssl | on
TimeZone | localtime
unix_socket_directory | /var/run/postgresql
work_mem | 256MB
Results of Bonnie++
Version 1.96 ------Sequential Output------ --Sequential Input-
--Random-
Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block--
--Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP
/sec %CP
voyager 95G 1400 93 27804 3 16324 2 2925 96 41636 3
374.9 4
Latency 7576us 233s 164s 15647us 13120ms
3302ms
Version 1.96 ------Sequential Create------ --------Random
Create--------
voyager -Create-- --Read--- -Delete-- -Create-- --Read---
-Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
/sec %CP
16 141 0 +++++ +++ 146 0 157 0 +++++ +++
172 0
Latency 1020ms 128us 9148ms 598ms 37us
485ms
1.96,1.96,voyager,1,1314988752,95G,,1400,93,27804,3,16324,2,2925,96,41636,3,374.9,4,16,,,,,141,0,+++++,+++,146,0,157,0,+++++,+++,172,0,7576us,233s,164s,15647us,13120ms,3302ms,1020ms,128us,9148ms,598ms,37us,485ms
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: wohlg@ai.wu.ac.at, heinz@langatium.net, wohlg@ai.wu-wien.ac.at, Albert.Weichselbraun@wu.ac.at
Subject: Re: Sudden drop in DBb performance
In-Reply-To: <4E61D6B4.9090804@ai.wu.ac.at>
* 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