Olá! Em Dom, 2008-09-28 às 13:06 +0000, Fernando Ike escreveu: > 2008/9/27 jose augusto (guto) carvalho <[EMAIL PROTECTED]>: > > Olá, > > Olá, > > > Estou com algumas dúvidas sobre instalação e performance. > > > > Tenho um servidor IBM System S-3560 quadcore com 6 discos SCSI, > > esta máquina vai segurar o novo banco de produção daqui. > > > > Coloquei 4 discos em RAID 10 + 1 disco para SPARE > > > > > O array do RAID 10 ficou com 293 GB. > > > > Deixei um disco separado para backup (173 GB). > > > > Instalei o Debian Lenny 64 bits (kernel 2.6.26.1-amd64) na máquina pois > > acima de 4 GB de memória é recomendável usar 64bits correto? > > > > Separei as partições da seguinte forma: > > > > /boot > > / > > /pgsql/indices (pg_clog) > > /pgsql/tabelas (base) > > /pgsql/tablespaces > > /pgsql/wal (pg_xlog) > > /pgsql/archives (global) > > /var > > /var/log > > /backup > > swap > > > Veja que o pg_clog[1][2][3] não é indices e tabelas não precisam > estar no diretório base. Pode estar em tablespaces[4].
Certo vou dar uma lida em tudo para separar melhor estas partições, entender onde ficam os índices, transaction logs, etc... Mas pelo o que entendi lendo isto: http://momjian.us/main/writings/pgsql/hw_performance/index.html > > O servidor tem 8 GB de RAM, deixei 4 GB de SWAP, acredito ser > > suficiente. > > > > Sistemas de arquivos: > > > > / > >> ext3 defauls > > > > /pgsql/indices > >> ext3 noatime,writeback > > > > /pgsql/tabelas > >> xfs noatime > > > > /pgsql/wal > >> ext3 noatime,writeback > > > > /pgsql/wal > >> ext3 noatime,writeback > > > > /pgsql/archives > >> ext3 noatime,writeback > > > > /var > >> ext3 defaults > > > > /var/log > >> ext3 defaults > > > > Fiz isto, está assim, mas fico pensando se não seria melhor fazer 2 > > raids 10 ao invés de apenas 1, assim poderia separar fisicamente índices > > e logs de transações das tabelas, será o mais indicado? > > Se tiver mais conjuntos de quatro discos, provavelmente será melhor > a performance. O problema se não for, terá um trabalho adicional. Entendi... > > [...] > > --- > > > > exemplo da compilação... > > > > ./configure --prefix=/opt/pgsql/8.3.4/ --enable-nls > > --enable-integer-datetimes --enable-thread-safety --enable-debug > > --disable-rpath --with-tcl --with-perl --with-python --with-pam > > --with-krb5 --with-openssl --with-ldap --with-gnu-ld > > Vc precisa de debug, kerberos, ldap, PL/TCL? E é o 8.2 ou 8.3? É o 8.2.9, é que fiz testes com o 8.3.4 antes. Procurei seguir o rules do pacote oficial do debian, por padrão vem tudo isto habilitado, teoricamente eu não preciso de ldap, pl/tcl, kerberos, nem debug... > > > criei o usuario postgres, criei o diretorio data e rodei o initdb. > > Ok. > > > depois movi tudo para as partições e criei links simbólicos no > > diretório, espero que seja o procedimento correto, se não for > > por favor me digam se tem um método mais eficiente ;) > > Vc pode usar o initdb no direorio /pgsql diretamente e mexer, não no > /opt/pgsql Certo, entendi. > > --- > > > > Fiz os seguintes ajustes no sysctl.conf > > > > kernel.shmmni = 128 > > kernel.shmmax = 2147483648 > > kernel.shmall = 33554432 Aqui mudei de kernel.shmmni de 128 para 18... > > > > vm.overcommit_memory = 2 > > fs.file-max = 65535 > > kernel.sem = 250 32000 100 128 > > > > net.core.rmem_default = 16777216 > > net.core.wmem_default = 16777216 > > net.core.wmem_max = 16777216 > > net.core.rmem_max = 16777216 > > > > ---referências---------------------------------------- > > > > Maximum size of shared memory segment (bytes) > > kernel.shmmax = 25% da minha memoria > > > > Total amount of shared memory available (bytes or pages) > > kernel.shmall = 25%/64 > > > > Maximum number of shared memory segments system-wide > > kernel.shmmni = não tenho referencia do parametro ideal > > > > net.core.rmem_default=65536 > > This sets the default OS receive buffer size for all types of > > connections. > > > > net.core.wmem_default=65536 > > This sets the default OS send buffer size for all types of connections. > > > > net.core.rmem_max=8388608 > > This sets the max OS receive buffer size for all types of connections. > > > > net.core.wmem_max=8388608 > > This sets the max OS send buffer size for all types of connections. > [...] > > > Mudando o I/O Scheduler dos discos... > > > > echo "deadline" > /sys/block/sda/queue/scheduler > > > > Isto é recomendável? > > Depende do tipo de banco de dados que está usando. ;) hummm... > > [...] > > Fiz os seguinte ajustes nos limits.conf > > > > postgres soft nofile 4096 > > postgres soft nproc 4096 > > postgres hard nofile 63536 > > postgres hard nproc 63536 > > > > > Configurações do postgresql.conf > > > > max_connections = 25 > > mudanças... shared_buffers = 1024 MB work_mem = 1024 MB > > temp_buffers = 64 MB > > maintenance_work_mem = 64 MB > > > > max_fsm_pages = 150000 > > max_fsm_relations = 250 > > > > wall_buffers = 256 KB > > > > stats_start_collector = on > > stats_row_level = on > > > > autocacumm = on > > autovacuum_naptime = 1min > > autovacuum_vacuum_threshold = 500 > > autovacuum_analyze_threshold = 250 > > autovacuum_vacuum_scale_factor = 0.2 > > autovacuum_analyze_scale_factor = 0.1 > > autovacuum_freeze_max_age = 200000000 > > autovacuum_vacuum_cost_delay = -1 > > autovacuum_vacuum_cost_limit = -1 > > > > Será que exagerei com as configurações de memória? > > Nopes. > Mas autovacuum com naptime com apenas um minuto e no 8.2 vai > sentar o seu servidor. Jóia, desliguei o autovacuum por enquanto, vou estudar os parâmetros do autovacuum ajustá-lo corretamente. > > > Liguei o autovacuum, no 8.2 faz tanta diferença quanto no 8.3 ? > > Não, aliás a configuração padrão no 8.2 derruba a performance. Então, vale a pena deixar ligado ou não? > > > > > Bom estou começando a estudar postgres, está será minha primeira > > implementação para ambiente em produção e quero fazer direito, agradeço > > se puderem me dar dicas e links para aprofundar os estudos ;) > > Que tal perguntar com alguns emails, separando os temas para ter > uma resposta melhor? É uma boa idéia, vou fazer isto. > > > Percebi uma lentidão ao criar bancos, 2 a 3 segundos, é normal? > > Depende do I/O. Certo... > > > Ainda estou analisando a lentidão, nem vou arriscar um chute no momento, > > continuo estudando as documentações do postgresql.org :) > > > > > > Referência: > 1 - http://www.postgresql.org/docs/8.3/interactive/backup-file.html > 2 - http://www.postgresql.org/docs/8.3/interactive/routine-vacuuming.html > 3 - http://www.postgresql.org/docs/8.3/interactive/app-pgresetxlog.html > 4 - http://www.postgresql.org/docs/8.3/interactive/manage-ag-tablespaces.html > 5 - Valeu já estou lendo!
signature.asc
Description: Esta é uma parte de mensagem assinada digitalmente
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
