<div dir="ltr"><div><div>Thanks Roger. <br><br>I am using postgres 9.1. And I got same error message after increasing kernel.shmmax to 128MB. And it happens when I tried to delete a set of 910 image files. This is frustrating because it took 910 * 5 seconds = 76minutes to finish deletion operation with error. Then I need to adjust parameters and wait for another 76 minutes to see results.<br>
<br></div>In case you might wonder why I need to delete files. It is simply because there's import error so I need to delete whatever imported into OMERO before doing import again. Not to mention import performance in OMERO is also low...<br>
<br></div>Anyway, I have over 12TB microscopy images accessed by couple hundred users. OMERO 5 seemed to be a good choice to manage these but now I can not be optimistic any more.<br><br>Thanks,<br>Yanling<br></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Tue, Jun 3, 2014 at 6:48 PM, Roger Leigh <span dir="ltr"><<a href="mailto:rleigh@dundee.ac.uk" target="_blank">rleigh@dundee.ac.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">On 03/06/14 19:25, Josh Moore wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Yanling,<br>
<br>
On Jun 3, 2014, at 7:28 PM, Yanling Liu wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Made mistake in outputting Blitz-0.log file. Here is what I found:<br>
<br>
2014-06-03 08:43:19,924 WARN [ o.h.h.ast.exec.<u></u>MultiTableDeleteExecutor]<br>
(2-thread-3) unable to drop temporary id table after use [ERROR: current<br>
transaction is aborted, commands ignored until end of transaction block]<br>
2014-06-03 08:43:19,927 ERROR [ ome.services.delete.Deletion]<br>
(2-thread-3) Failure during DeleteHandle.steps :<br>
...<br>
<br>
From my limited knowledge about java and postgres, this looks like a<br>
postgres issue. Shall I change max_locks_per_transaction? If so what would<br>
be optimal value?<br>
<br>
</blockquote>
...<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Tue, Jun 3, 2014 at 9:29 AM, Yanling Liu <<a href="mailto:vrnova@gmail.com" target="_blank">vrnova@gmail.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
...<br>
But I do found something in postgres log file:<br>
<br>
2014-06-03 08:43:19 EDT WARNING: out of shared memory<br>
2014-06-03 08:43:19 EDT ERROR: out of shared memory<br>
2014-06-03 08:43:19 EDT HINT: You might need to increase<br>
max_locks_per_transaction.<br>
<br>
</blockquote></blockquote>
...<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In postgresql.conf I have following settings:<br>
<br>
max_connections = 100<br>
#max_locks_per_transaction = 64 # min 10<br>
<br>
Mote the max_locks_per_transaction is commented out by default. I am not<br>
an expert on postgres and I would appreciate if you may provide some hints<br>
on how to set postgres parameters properly for OMERO.<br>
</blockquote></blockquote></blockquote>
<br>
</div></div><a href="http://www.postgresql.org/docs/9.3/static/runtime-config-locks.html" target="_blank">http://www.postgresql.org/<u></u>docs/9.3/static/runtime-<u></u>config-locks.html</a><br>
There shouldn't be a need to fiddle with these settings unless you see<br>
problems specifically relating to them.<div class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Since you likely still have available resources on your system with<br>
8 GB, one solution would be to give increase the shared memory<br>
setting of your system. See the "Linux" section of<br>
<a href="http://www.postgresql.org/docs/9.1/static/kernel-resources.html" target="_blank">http://www.postgresql.org/<u></u>docs/9.1/static/kernel-<u></u>resources.html</a><br>
</blockquote>
<br></div>
As a caveat, do make sure to check the documentation for the version of<br>
PostgreSQL you are using. More recent versions of PostgreSQL (>= 9.3)<br>
no longer use SYSV SHM significantly and so these settings might not<br>
apply to you. See e.g.<br>
<a href="http://www.postgresql.org/docs/9.3/static/kernel-resources.html" target="_blank">http://www.postgresql.org/<u></u>docs/9.3/static/kernel-<u></u>resources.html</a> and<br>
<a href="http://rhaas.blogspot.co.uk/2012/06/absurd-shared-memory-limits.html" target="_blank">http://rhaas.blogspot.co.uk/<u></u>2012/06/absurd-shared-memory-<u></u>limits.html</a>.<br>
In the case of PostgreSQL 9.3 and later you can increase shared_buffers<br>
as high as you like providing you have the system memory (and swap<br>
space) to back it.<br>
<br>
<br>
Regards,<br>
Roger<br>
<br>
<br>
The University of Dundee is a registered Scottish Charity, No: SC015096<br>
</blockquote></div><br></div>