A situação em que tenho um banco de dados postgresql 9.2 é bastante atualizado o tempo todo. Portanto, o sistema está ligado à E / S e, atualmente, estou pensando em fazer outra atualização, só preciso de algumas instruções sobre como começar a melhorar.
Aqui está uma imagem de como a situação estava 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 parece em uma janela mais detalhada de 3 horas:
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 é pequeno, geralmente atualizado 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 o máximo possível, e a configuração dos servidores (kernel do linux e conf do postgres) também é bastante otimizada.
Hardware O hardware é um servidor dedicado com 32 GB de ram ECC, 4x SAS de discos de 600 GB a 15.000 rpm em um array RAID 10, controlado por um controlador de ataque LSI com BBU e um processador Intel Xeon E3-1245 Quadcore.
Questões
- O desempenho observado pelos gráficos é razoável para um sistema desse 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.)?
- Ao fazer uma atualização de hardware, o número de discos é essencial 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 ataque. As coisas melhoraram bastante, como você pode ver a seguir, o desempenho máximo de E / S melhorou cerca de 6 a 10 vezes - e isso é ótimo!
No entanto, eu esperava algo mais ou menos 20 a 50 vezes melhor, 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 limita 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 tuningSaída de MegaCli64 -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: Nofonte
synchronous_commit = off, depois de ler os documentos em postgresql.org/docs/9.2/static/wal-async-commit.html . (3) Como é a sua configuração? Por exemplo. resultados desta consulta:SELECT name, current_setting(name), source FROM pg_settings WHERE source NOT IN ('default', 'override');synchronous_commit: 'A confirmação assíncrona é uma opção que permite que as transações sejam concluídas mais rapidamente, com o custo de perder as transações mais recentes se o banco de dados travar.'Respostas:
Sim, como um disco rígido - mesmo SAS - tem uma cabeça que leva tempo para se mover.
Deseja uma atualização HUGH?
Mate os discos SAS, vá para SATA. Conecte o SSD SATA - nível empresarial, como o Samsung 843T.
Resultado? Você pode fazer cerca de 60.000 (ou seja, 60 mil) IOPS por unidade.
Essa é a razão pela qual o SSD é um assassino no espaço do banco de dados e muito mais barato que qualquer unidade SAS. O disco giratório Phyiscal simplesmente não consegue acompanhar os recursos IOPS dos discos.
Seus discos SAS eram uma escolha medíocre para começar (muito grande para obter muitas IOPS). Para um banco de dados de uso mais alto (discos menores significariam muito mais IOPS), mas no final o SSD é o fator decisivo aqui.
Em relação ao software / kernel. Qualquer banco de dados decente fará muitas IOPS e liberará os buffers. O arquivo de log precisa ser ESCRITO para garantir condições básicas de ÁCIDO. As únicas músicas do kernel que você poderia fazer invalidariam sua integridade transacional - parcialmente você PODE se safar disso. O controlador Raid no modo de gravação reversa fará isso - confirme a gravação como liberada mesmo que não esteja - mas pode fazê-lo porque se supõe que a BBU seja segura no dia em que a energia falhar. Qualquer coisa que você faça mais alto no kernel - é melhor saber que você pode viver com os efeitos colaterais negativos.
No final, os bancos de dados precisam de IOPS, e você pode se surpreender ao ver quão pequena é sua configuração em comparação com outras aqui. Vi bases de dados com mais de 100 discos apenas para obter as IOPS necessárias. Hoje, na verdade, você compra SSD e adota tamanho - eles são tão superiores nos recursos de IOPS que não faz sentido lutar contra esse jogo com drives SAS.
E sim, seus números de IOPS não parecem ruins para o hardware. Dentro do que eu esperaria.
fonte
Se você puder pagar, coloque o pg_xlog em um par de unidades RAID 1 separadas em seu próprio controlador com RAM suportada por bateria configurada para write-back. Isso é verdade mesmo se você precisar usar a oxidação rotativa para pg_xlog enquanto todo o resto estiver no SSD.
Se você usa SSD, verifique se ele possui um super capacitor ou outro meio para persistir todos os dados em cache em caso de falta de energia.
Em geral, mais eixos significa mais largura de banda de E / S.
fonte
Supondo que você esteja executando no Linux, certifique-se de definir o planejador de E / S do disco.
De experiências anteriores, mudar para noop fornecerá uma velocidade bastante substancial (especialmente para SSD).
A alteração do agendador de E / S pode ser feita em tempo real, sem tempo de inatividade.
ie eco noop> / sys / block // fila / agendador
Consulte: http://www.cyberciti.biz/faq/linux-change-io-scheduler-for-harddisk/ para obter mais informações.
fonte