Se utilizar smaty, ele não possui um cache??? Não estaria resolvendo o
problema de varias requisições???

Desculpe perguntar isto aqui, mas como já estamos no assunto.

Em 12/03/08, Jorge Vilela <[EMAIL PROTECTED]> escreveu:
>
> Algum de vocês conhece algum framework para PHP que faça esse tipo de
> coisa? spool + cache?
>
> Estou pensando em melhorar o acesso ao banco de dados das minhas
> aplicações pois estão ficando muito pesadas também... E hoje trabalho com
> php/postgres...
>
>
>
>
>
>
> []'s
> Jorge
>
>
>
>
> 2008/3/12 Nilson Chagas <[EMAIL PROTECTED]>:
>
> > RSRSRSRS'
> >
> > Foi mal este negocio me deixou muito pensativo.
> >
> > Veja o que ele me passou no dia que deu problema apos o upgrade dos
> > servidores:
> >
> > Está dando 'dead lock' na tabela spnet_users, ou seja, várias transações
> > simultâneas nesta tabela em que uma conxão fica aguardando algo terminar na
> > outra e vice versa, condição que nunca termina.
> >
> > Abaixo segue a lista de conexões que estavam ativas. Vou reiniciar o
> > banco, porque o web server não estou nem conseguindo logar na máquina em
> > função disto.
> >
> > Será necessário analisar o que pode estar ocorrendo, haja vista que as
> > configurações basicamente são as mesmas. A única alteração é a versão do PHP
> > (4->5) e do MySQL ( 4->5).
> >
> > Agnaldo
> >
> > mysql> show processlist;
> > +---------+--------+------------------------------------------+---------+---------+------+----------------+-----------------------------------------
> > -------------------------------------------------------------+
> > | Id      | User   | Host                                     | db
> > | Command | Time | State          |
> > Info
> > |
> > +---------+--------+------------------------------------------+---------+---------+------+----------------+-----------------------------------------
> > -------------------------------------------------------------+
> > | 1299383 | 1040a2 | ds-1040-1.dedicados.laniway.com.br:47183 | 1040db2
> > | Sleep   |   45 |                |
> > NULL
> > |
> > | 1299393 | 1040a2 | ds-1040-1.dedicados.laniway.com.br:47193 | 1040db2
> > | Sleep   |   74 |                |
> > NULL
> > |
> > | 1299402 | 1040a2 | ds-1040-1.dedicados.laniway.com.br:47202 | 1040db2
> > | Sleep   |   16 |                |
> > NULL
> > |
> > | 1299412 | 1040a2 | ds-1040-1.dedicados.laniway.com.br:47212 | 1040db2
> > | Sleep   |   74 |                |
> > NULL
> > |
> > | 1299421 | 1040a2 | ds-1040-1.dedicados.laniway.com.br:47221 | 1040db2
> > | Query   |    9 | Locked         | SELECT count(uid) FROM spnet_users
> >                              WHERE uid=14065 and banned='N' and moderate
> > |
> >
> >
> >
> > Em 12/03/08, Benedito A. Cruz <[EMAIL PROTECTED]> escreveu:
> >
> > >
> > >
> > >   Dead block ou deadlock?
> > >
> > >   São coisas bem diferentes.
> > >
> > >
> > > Nilson Chagas wrote:
> > > > Isto foi me passado:
> > > >
> > > > "São dois servidores AMD 64 4400+ Dual Core com HD de 500GB e 2GB de
> > > RAM.
> > > >
> > > > Os servidores estão (deveriam estar) conectados à internet a uma
> > > > velocidade de 100Mbps (está a 10Mbps e já estou resolvendo isto).
> > > >
> > > > Um servidor roda o webserver e o outro os bancos mysql e pgsql.
> > > >
> > > > Cada servidor tem uma franquia de tráfego de 1.5TB."
> > > >
> > > > O problema no site atual começou acontecer depois de dois dias do
> > > novo
> > > > servidor no ar. Quando o site passava de 500 usuarios estava dando
> > > > dead block no banco que é mysql.
> > > >
> > > > Então ele me mandou aquela alertando que o problema no postgresql,
> > > > pode ser pior, se não for feito um tratamento com um cache.
> > > >
> > > > Em 12/03/08, *William Leite Araújo* <
> > > [EMAIL PROTECTED]
> > >
> > > > <mailto:[EMAIL PROTECTED]>> escreveu:
> > >
> > > >
> > > >           Bom, temos números para o problema? Número máximo de
> > > >     conexões simultâneas? Existe "intranet" (área que exija
> > > >     autenticação)? As transações possuem um "equilíbrio" ou
> > > >     inserção/atualização é mais freqüente?
> > > >
> > > >           Qual o hardware para dar suporte a tais requisições?
> > > >
> > > >           Qualquer servidor mal-configurado gerará problemas. E nem
> > > >     todos são ligados diretamente com a solução de banco de dados. O
> > > >     apache por exemplo, possui um cache de conexões.
> > > >
> > > >           O que quero dizer é que esse tipo de decisão demanda de um
> > > >     conhecimento maior sobre o problema a ser enfrentado e,
> > > >     principalmente, entendimento técnico das soluções a serem
> > > usadas.
> > > >
> > > >            E quanto à opinião do administrador da hospedagem, bem,
> > > ou
> > > >     ele gosta do MySQL e não quer aprender nada do postgresql, ou
> > > >     possui apenas uma máquina rodando tudo...
> > > >
> > > >
> > > >     --
> > > >     William Leite Araújo
> > > >     Analista de Banco de Dados - QualiConsult
> > > >     _______________________________________________
> > > >     pgbr-geral mailing list
> > > >     pgbr-geral@listas.postgresql.org.br
> > >
> > > >     <mailto:pgbr-geral@listas.postgresql.org.br>
> > >
> > > >
> > > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
> > > >
> > > >
> > >
> > > >
> > > ------------------------------------------------------------------------
> > >
> > > >
> > > > _______________________________________________
> > > > pgbr-geral mailing list
> > > > pgbr-geral@listas.postgresql.org.br
> > > > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
> > > >
> >
> >
> >
> > _______________________________________________
> > pgbr-geral mailing list
> > pgbr-geral@listas.postgresql.org.br
> > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
> >
> >
>
> _______________________________________________
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
>
_______________________________________________
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Responder a