Temos observado que o nosso servidor expresso está muito lento. Usando o top percebemos que o processo do openldap server está usando muita CPU e deixando os demais serviços lentos. Vi também que o openldap fica assim pesado quando há mais de 80 conexões estabelecidas. No expressoAdmin isso acontece quando é exibido acima de 140 sessões.

Alguma idéia?

Arquivo anexado:   top.jpg (37.90 KB)

---

Olá!

Algumas perguntas para mapeamos o ambiente:
1. Quais os índices do OpenLDAP?
2. Quantas threads configuradas?
3. Quanto de memória está reservado para o BDB (via DB_CONFIG ou dentro do slapd.conf)?
4. Quais serviços estão "pendurados" neste servidor LDAP?
5. Está utilizando algum tipo de cache para os serviços, como o NSCD?

Att,

Respondendo as perguntas.

O servidor só está sendo usado para o expresso. Não estamos usando NSCD.


slapd.conf

sizelimit 150
timelimit 30
tool-threads 2
threads 16
cachesize 1000000
idlcachesize 1000000
dbcachesize 100000000
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/qmailuser.schema
include /etc/openldap/schema/phpgwaccount.schema
include /etc/openldap/schema/samba.schema
include /etc/openldap/schema/phpgwcontact.schema
schemacheck on
#R#loglevel 1
checkpoint 512 30
allow bind_v2
pidfile /var/run/openldap/slapd.pid
argsfile /var/run/openldap/slapd.args
database bdb
suffix "dc=pe,dc=gov,dc=br"
rootdn "cn=admin,dc=pe,dc=gov,dc=br"
rootpw {MD5}e9B9UgQ7WitT03cGGEFqnA==
directory /var/lib/ldap
index mail,mailAlternateAddress,mailForwardingAddress,objectClass,memberUid,uidNumber,deliveryMode,accountStatus,phpgwAccountType,gidNumber,phpgwAccountStatus,ou pres,eq
index uid,cn,sn,givenName pres,eq,sub
lastmod on

DB_CONFIG

set_cachesize 0 2097152 0
set_cachesize 0 30625088 1
set_flags DB_LOG_AUTOREMOVE

#DM#Setando Valores dos logs
set_lg_regionmax 262144
set_lg_max 10485760
set_lg_bsize 2097152
set_lg_dir /var/lib/ldap/

set_lk_max_objects 1500
set_lk_max_locks 1500
set_lk_max_lockers 1500

Blz!

Sugiro vc utilizar estes índices:
index objectClass,memberUid,uidNumber,deliveryMode,accountStatus,phpgwAccountType,gidNumber,phpgwAccountStatus pres,eq
index mail,uid,cn,sn,ou,givenName,displayName pres,eq,sub
index mailSenderAddress,mailForwardingAddress,mailAlternateAddress eq,sub

Teste o "threads" com 32 (são mais que 4 CPUs, correto?). Se não ficar bom, teste com 8.

Deixe o "set_cachesize" (do DB_CONFIG) com, no mínimo, o espaço utilizado pelos arquivos de índice /var/lib/ldap/*.bdb. Não sei o que DB_LOG_AUTOREMOVE faz no "set_flags", mas coloque tbm o "DB_TXN_NOSYNC". Pode ser um pouco arriscado, mas melhora bem o desempenho.

Altere o cachesize para 10.000, o dncachesize para 20.000 e o idlcachesize para 30.000.

Cara, faz um teste aí... Mas acredito que a alteração nos índices e aumento da memória do BDB fará uma grande diferença. Seria bom ativar os logs (loglevel 256) por um momento a fim de buscar os atributos não indexados...

Att,

Valmir, houve melhora no LDAP com as alterações propostas?

Att,

Oi Willian,

Eu já havia feito a maior parte das otimizações que vc propôs. O problema foi que nós a uns 6 meses atrás, usamos uma versão modificada do para criar usuários em lote para rodar via linha de comando. Ao executar o mesmo estava percebemos que alguns usuários não estavam recebendo email, assom descobrimos que o script estava inserindo um caracter estranho no final dos emails dos usuários. Na época para contornarmos o problema modificamos o filtro mailboxes do postfix para ficar assim:

(&(|(mail=%s*)(mailAlternateAddress=%s))(objectClass=posixAccount)(phpgwAccountType=u)(accountStatus=active))

acabamos esquecendo de pesquisar depois qual seria o problema. A semana passada de repente me veio na lembraça este asterisco colocado após mail. O que aconteceu e que com o asterisco na busca, ao invês de fazer uma busca direta batendo com o índice, o que daria uma resposta bem rápida, o servidor estava tendo que fazer uma busca completa, o que é algo bem mais lento e para todo email que chegava. Descobri que o caracter que estava no final dos emails do pessoal era o "\n". Assim eu fiz um script para retirar o "\n" de todos os emails com problemas da base ldap e retirei o asterisco que não era mais necessário. Assim resolveu-se o nosso problema!!!!!!!


Valeu

Olá Valmir!

Que bom que encontraram a causa do problema! Legal que não teve nada haver com o Expresso em si e por isso é importante sempre comentar sobre a solução...

Valeu!

Att,