Como otimizar o banco de dados para I/O pesado de atualizações (software e hardware)

A situação Eu tenho um banco de dados postgresql 9.2 que é bastante atualizado o tempo todo. O sistema está, portanto, vinculado à E/S, e atualmente estou pensando em fazer outra atualização, só preciso de algumas orientações sobre onde começar a melhorar.

Aqui está uma imagem de como a situação ficou nos últimos 3 meses:

Como você pode ver, as operações de atualização são responsáveis ​​pela maior parte da utilização do disco. Aqui está outra imagem de como a situação fica em uma janela de 3 horas mais detalhada:

Como você pode ver, a taxa de gravação de pico é de cerca de 20 MB/s

Software O servidor está executando o Ubuntu 12.04 e o postgresql 9.2. O tipo de atualizações são pequenas atualizações normalmente em linhas individuais identificadas por ID. Por exemplo UPDATE cars SET price=some_price, updated_at = some_time_stamp WHERE id = some_id. Eu removi e otimizei os índices tanto quanto eu acho que é possível, e a configuração dos servidores (tanto o kernel linux quanto o postgres conf) também está bastante otimizada.

Hardware O hardware é um servidor dedicado com 32 GB de RAM ECC, 4 discos SAS de 600 GB e 15.000 rpm em um array RAID 10, controlado por um controlador RAID LSI com BBU e um processador Intel Xeon E3-1245 Quadcore.

Perguntas

• O desempenho visto pelos gráficos é razoável para um sistema deste calibre (leitura/gravação)?
• Portanto, devo me concentrar em fazer uma atualização de hardware ou investigar mais profundamente o software (ajustes do kernel, confs, consultas etc.)?
• Se estiver fazendo uma atualização de hardware, o número de discos é fundamental para o desempenho?

------------------------------ATUALIZAR------------------- ----------------

Agora atualizei meu servidor de banco de dados com quatro SSDs Intel 520 em vez dos antigos discos SAS de 15k. Estou usando o mesmo controlador de raid. As coisas melhoraram bastante, como você pode ver a seguir, o desempenho de E/S de pico melhorou cerca de 6 a 10 vezes - e isso é ótimo!. No entanto, eu esperava algo mais como uma melhoria de 20 a 50 vezes de acordo com as respostas e os recursos de E/S dos novos SSDs. Então aqui vai outra pergunta.

Nova pergunta Há algo na minha configuração atual que está limitando o desempenho de E/S do meu sistema (onde está o gargalo)?

Minhas configurações:

/etc/postgresql/9.2/main/postgresql.conf

data_directory = '/var/lib/postgresql/9.2/main'
hba_file = '/etc/postgresql/9.2/main/pg_hba.conf'
ident_file = '/etc/postgresql/9.2/main/pg_ident.conf'
external_pid_file = '/var/run/postgresql/9.2-main.pid'
listen_addresses = '192.168.0.4, localhost'
port = 5432
unix_socket_directory = '/var/run/postgresql'
wal_level = hot_standby
synchronous_commit = on
checkpoint_timeout = 10min
archive_mode = on
archive_command = 'rsync -a %p [email protected]:/var/lib/postgresql/9.2/wals/%f </dev/null'
max_wal_senders = 1
wal_keep_segments = 32
hot_standby = on
log_line_prefix = '%t '
datestyle = 'iso, mdy'
lc_messages = 'en_US.UTF-8'
lc_monetary = 'en_US.UTF-8'
lc_numeric = 'en_US.UTF-8'
lc_time = 'en_US.UTF-8'
default_text_search_config = 'pg_catalog.english'
default_statistics_target = 100
maintenance_work_mem = 1920MB
checkpoint_completion_target = 0.7
effective_cache_size = 22GB
work_mem = 160MB
wal_buffers = 16MB
checkpoint_segments = 32
shared_buffers = 7680MB
max_connections = 400 

/etc/sysctl.conf

# sysctl config
#net.ipv4.ip_forward=1
net.ipv4.conf.all.rp_filter=1
net.ipv4.icmp_echo_ignore_broadcasts=1
# ipv6 settings (no autoconfiguration)
net.ipv6.conf.default.autoconf=0
net.ipv6.conf.default.accept_dad=0
net.ipv6.conf.default.accept_ra=0
net.ipv6.conf.default.accept_ra_defrtr=0
net.ipv6.conf.default.accept_ra_rtr_pref=0
net.ipv6.conf.default.accept_ra_pinfo=0
net.ipv6.conf.default.accept_source_route=0
net.ipv6.conf.default.accept_redirects=0
net.ipv6.conf.default.forwarding=0
net.ipv6.conf.all.autoconf=0
net.ipv6.conf.all.accept_dad=0
net.ipv6.conf.all.accept_ra=0
net.ipv6.conf.all.accept_ra_defrtr=0
net.ipv6.conf.all.accept_ra_rtr_pref=0
net.ipv6.conf.all.accept_ra_pinfo=0
net.ipv6.conf.all.accept_source_route=0
net.ipv6.conf.all.accept_redirects=0
net.ipv6.conf.all.forwarding=0
# Updated according to postgresql tuning
vm.dirty_ratio = 10
vm.dirty_background_ratio = 1
vm.swappiness = 0
vm.overcommit_memory = 2
kernel.sched_autogroup_enabled = 0
kernel.sched_migration_cost = 50000000

/etc/sysctl.d/30-postgresql-shm.conf

# Shared memory settings for PostgreSQL
# Note that if another program uses shared memory as well, you will have to
# coordinate the size settings between the two.
# Maximum size of shared memory segment in bytes
#kernel.shmmax = 33554432
# Maximum total size of shared memory in pages (normally 4096 bytes)
#kernel.shmall = 2097152
kernel.shmmax = 8589934592
kernel.shmall = 17179869184
# Updated according to postgresql tuning

Saída deMegaCli64 -LDInfo -LAll -aAll

Adapter 0 -- Virtual Drive Information:
Virtual Drive: 0 (Target Id: 0)
Name                :
RAID Level          : Primary-1, Secondary-0, RAID Level Qualifier-0
Size                : 446.125 GB
Sector Size         : 512
Is VD emulated      : No
Mirror Data         : 446.125 GB
State               : Optimal
Strip Size          : 64 KB
Number Of Drives per span:2
Span Depth          : 2
Default Cache Policy: WriteBack, ReadAhead, Direct, Write Cache OK if Bad BBU
Current Cache Policy: WriteBack, ReadAhead, Direct, Write Cache OK if Bad BBU
Default Access Policy: Read/Write
Current Access Policy: Read/Write
Disk Cache Policy   : Disk's Default
Encryption Type     : None
Is VD Cached: No