-
Incident report
-
Resolution: Duplicate
-
Major
-
None
-
2.0.3
-
Redhat Enterprise Linux 6.3/Postgresql 9.1/96 GB of RAM, 12 CPU Cores, 4-15K RPM sas drives, RAID 1+0)
We frequently see sharelock problems with Zabbix when updating the items table. Unlike other Jira bugs, where this is happening on the ids table, we are seeing this on the items table as a result of concurrent updates and row level locking features provided by Postgresql.
The errors we see are:
2012-11-01 00:14:29 PDT zabbix zabbix 127.0.0.1 - DETAIL: Process 5985 waits for ShareLock on transaction 48349150; blocked by process 5983.
Process 5983 waits for ShareLock on transaction 48349166; blocked by process 5985.
Process 5985: update items set lastclock=1351754060,lastns=334498000,prevvalue=lastvalue,lastvalue='1351754060' where itemid=23420;
update items set lastclock=1351754061,lastns=339616000,prevvalue=lastvalue,lastvalue='99.967760' where itemid=23421;
update items set lastclock=1351754066,lastns=667765507,prevvalue=lastvalue,lastvalue='0.137500' where itemid=23897;
update items set lastclock=1351754066,lastns=669010892,prevorgvalue='4662521788565',prevvalue=lastvalue,lastvalue='77696' where itemid=23957;
update items set lastclock=1351754058,lastns=314361000,prevvalue=lastvalue,lastvalue='478419185664' where itemid=24798;
update items set lastclock=1351754059,lastns=323575000,prevvalue=lastvalue,lastvalue='0.000000' where itemid=24799;
update items set lastclock=1351754060,lastns=334898000,prevvalue=lastvalue,lastvalue='0.016120' where itemid=24800;
update items set lastclock=1351754061,lastns=343300000,prevvalue=lastvalue,lastvalue='0.003640' where itemid=24801;
update items set lastclock=1351754058,lastns=317769000,prevorg
Process 5983: update items set lastclock=1351754065,lastns=641967535,prevorgvalue='29892503160',prevvalue=lastvalue,lastvalue='7791' where itemid=23776;
update items set lastclock=1351754065,lastns=644268407,prevvalue=lastvalue,lastvalue='0.145000' where itemid=23896;
update items set lastclock=1351754064,lastns=216544563,prevorgvalue='0',prevvalue=lastvalue,lastvalue='0' where itemid=23955;
update items set lastclock=1351754065,lastns=642674637,prevorgvalue='9239423731381',prevvalue=lastvalue,lastvalue='7635408' where itemid=23956;
update items set lastclock=1351754053,lastns=273681000,prevvalue=lastvalue,lastvalue='87.648513' where itemid=24073;
update items set lastclock=1351754053,lastns=282197000,prevvalue=lastvalue,lastvalue='495' where itemid=24733;
update items set lastclock=1351754054,lastns=284275000,prevvalue=lastvalue,lastvalue='0.000000' where itemid=24734;
update items set lastclock=1351754053,lastns=278317000,prevvalue=lastvalue,lastvalue='96.814452' where itemid=24793;
update items set lastclock=1351754054
2012-11-01 00:14:29 PDT zabbix zabbix 127.0.0.1 - HINT: See server log for query details.
As of this morning, we have seen this 32 times where transactions appear to be walking on top of each other. This has been an issue since Zabbix 2.0.1 when we started to use Zabbix a large university environment. This issue is causing a performance bottleneck as Postgres must wait for one transaction to finish before committing another.
- duplicates
-
ZBX-2494 deadlock between server and frontend
- Closed