Having performance problems.

Поиск
Список
Период
Сортировка
От eanxgeek@comcast.net
Тема Having performance problems.
Дата
Msg-id 040420051427.2521.42514EEB000231AF000009D92207001641050A0A0998020E0A@comcast.net
обсуждение исходный текст
Список pgsql-admin
First let me start by saying I am pretty new to Postgresql.  To date I have only worked with small databases, I now
havea database that isn't big but is big enough to create performance issues.  The database is roughly 450 MB.    I
havetwo tables of interest; logs and hosts.  At one point I had the following sql: 

 SELECT * FROM hosts, logs where (logs.host_id = hosts.host_id) ORDER BY date DESC, time DESC;

This took over 1000 seconds to execute.

I then upgraded to PGSQL 8.0.1 and created tablespace logs_t and hosts_t, these are on separate controllers and
separatedisks. 
           List of tablespaces
Name    |  Owner   |    Location
------------+----------+-----------------
 hosts_t    | postgres | /pgdata/hosts_t
 logs_t     | postgres | /pgdata/logs_t

I then altered the tables logs and hosts to use the new tablespace respectively and I changed the sql to read:

SELECT hostname,facility,priority,level,tag,date,time,program,msg,seq FROM hosts, logs where (logs.host_id =
hosts.host_id)ORDER BY date DESC, time DESC; 

Under 7.x my PGDATA was on /pgdata; however, for 8.x I have left it in in its default location of /var/lib/pgsql.  So
whatis happening now is: 
1. I am still seeing all 4x700 MHz CPUs go to 95%+ IOWAIT, appears that /var is the hardest hit.
2. SELECT hostname,facility,priority,level,tag,date,time,program,msg,seq FROM hosts, logs where (logs.host_id =
hosts.host_id);works but takes awhile; however, adding the ORDER BY condition causes the SQL to execute to the point
that/var becomes full and the SQL exits with: 
ERROR:  could not write block 81940 of temporary file: No space left on device
HINT:  Perhaps out of disk space?

What parameters can I start "tweaking" and what can I do to addres the issue of /var filling up?  Below are some of my
kerneland database settings: 

effective_cache_size           | 1000
maintenance_work_mem           | 16384
max_connections                | 32
shared_buffers                 | 64
------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status
0x0052e2c1 38043648   postgres  600        1540096    2



В списке pgsql-admin по дате отправления:

Предыдущее
От: "Lee Wu"
Дата:
Сообщение: Re: is this normal?
Следующее
От: Jason DiCioccio
Дата:
Сообщение: Re: is this normal?