Postgresql deadlocks

[Tomas Vondra]

On 2.3.2012 19:54, Martin Tiršel wrote:
>> Pokud můžete, zaměřte se na pořadí v jakém měníte data. Problém je když
>> transakce mění data v různém pořadí (např. jedna transakce nejdříve
>> updatne 1152 a druhý 1153 zatím co druhá 1153 a až pak 1152).
>>
> 
> Ano, je to tym, ze si transakcie prepisuju rovnake dat. Ide o to, ze sa
> prevedie nahodny vyber 2-3 inzeratov a tym sa updatne view counter,
> lenze v rovnakej chvili dojde k vyberu dalsich 2-3 inzeratov v ramci
> dalsej transakcie, kde jeden alebo viacero inzeratov je s rovnakym ID
> ako u prvej transakcie.
> 
> Vyriesil by to asi SELECT FOR UPDATE, co by blokovalo ine transakcie,
> ale to by mohlo mat negativny dopad na vykon a skalovatelnost. Kolega
> navrhuje pouzit memcached, tam drzat countery a treba raz za minutu
> zapisat, co mne sa velmi nepaci. Zrejme to budem riesit dalsou tabulkou,
> kde sa kazde zobrazenie zapise ako insert, v urcitych intervaloch budem
> robit prepocty a sucasny view stlpec pouzijem len ako cache.

Ne, tohle jde vyresit velmi jednoduse setridenim tech dat. Proste si je
po nahodnem vyberu setridte napr. podle ID inzeratu (nebo cehokoliv
dalsiho, dulezite je aby to ve vsech transakcich bylo stejne) a
updatujte je v tomhle poradi. Deadlocky zmizi.

>>> Medzitym  su v logoch tieto zaznamy, ale to s tym zrejme nesuvisi:
>>>
>>> 2012-03-01 14:54:01 CET LOG:  could not receive data from client:
>>> Connection reset by peer
>>> 2012-03-01 14:54:01 CET LOG:  unexpected EOF on client connection
>>> 2012-03-01 14:54:02 CET LOG:  could not receive data from client:
>>> Connection reset by peer
>>> 2012-03-01 14:54:02 CET LOG:  unexpected EOF on client connection
>>> 2012-03-01 14:56:02 CET LOG:  could not receive data from client:
>>> Connection reset by peer
>>> 2012-03-01 14:56:02 CET LOG:  unexpected EOF on client connection
>>> 2012-03-01 14:56:02 CET LOG:  could not receive data from client:
>>> Connection reset by peer
>>> 2012-03-01 14:56:02 CET LOG:  unexpected EOF on client connection
>>
>> Tohle většinou znamená že spadlo spojení (např. kvůli síťové chybě) nebo
>> klientská aplikace z nějakého neznámého důvodu spadla aniž by se
>> korektně odpojila (tj. buď je programátor čuně a nezavolal "close" nebo
>> aplikace např. spadla na segfault).
>>
> 
> Malo by to byt medzi dvomi virtualmi, tkaze siet by som vylucil a django
> nemyslim, ze bude prasacky napisane :) Da sa tych informacii do logu
> vypisat viacej upravenim niektoreho parametru configu?

O Djangu jsem slysel ruzne veci, ale osobni zkusenost s nim nemam. Ano,
do configu lze doplnit veci ktere vam pri identifikaci vinika pomohou.
Slouzi k tomu promenna log_line_prefix - osobne bych tam dal napr. toto:

log_line_prefix = '%t %h db=%d user=%u '

coz vam na zacatku radky vypise cas, IP klienta, databazi a uzivatele.
Zformatujte si to dle libosti, detaily viz:

http://www.postgresql.org/docs/9.1/static/runtime-config-logging.html

T.