Temporary error accessing NumPy tickets
Hi, When I access tickets, for example: http://projects.scipy.org/numpy/ticket/2185 then sometimes I get: Trac detected an internal error: OperationalError: database is locked For example yesterday. A refresh in about a minute fixed the problem. Today it still lasts at the moment. Ondrej
Ondřej Čertík <ondrej.certik <at> gmail.com> writes:
When I access tickets, for example:
http://projects.scipy.org/numpy/ticket/2185
then sometimes I get:
Trac detected an internal error: OperationalError: database is locked
For example yesterday. A refresh in about a minute fixed the problem. Today it still lasts at the moment.
The failures are probably partly triggered by the machine running out of memory. It runs services on mod_python, which apparently slowly leaks. Someone (who?) with root access on the machine needs to restart Apache. (Note: "apachectl graceful" is not enough to correct this, it needs a real restart of the process.) Longer term solution is to move out of mod_python (mod_wsgi likely, going to CGI will create other performance problems), or to transition the stuff there to a more beefy server. -- Pauli Virtanen
On Fri, Aug 31, 2012 at 9:35 AM, Pauli Virtanen <pav@iki.fi> wrote:
Ondřej Čertík <ondrej.certik <at> gmail.com> writes:
When I access tickets, for example:
http://projects.scipy.org/numpy/ticket/2185
then sometimes I get:
Trac detected an internal error: OperationalError: database is locked
For example yesterday. A refresh in about a minute fixed the problem. Today it still lasts at the moment.
The failures are probably partly triggered by the machine running out of memory. It runs services on mod_python, which apparently slowly leaks. Someone (who?) with root access on the machine needs to restart Apache. (Note: "apachectl graceful" is not enough to correct this, it needs a real restart of the process.)
I see.
Longer term solution is to move out of mod_python (mod_wsgi likely, going to CGI will create other performance problems), or to transition the stuff there to a more beefy server.
Or move the tickets to github. Yesterday it was very unreliable (I had to wait a long time before a comment was posted, and about 50% of the time it was not posted due to the database error). So I just created a github issue for the same thing and posted my comments there. Then I could work fast. Ondrej
On Fri, Aug 31, 2012 at 11:35 AM, Pauli Virtanen <pav@iki.fi> wrote:
Ondřej Čertík <ondrej.certik <at> gmail.com> writes:
When I access tickets, for example:
http://projects.scipy.org/numpy/ticket/2185
then sometimes I get:
Trac detected an internal error: OperationalError: database is locked
For example yesterday. A refresh in about a minute fixed the problem. Today it still lasts at the moment.
The failures are probably partly triggered by the machine running out of memory. It runs services on mod_python, which apparently slowly leaks. Someone (who?) with root access on the machine needs to restart Apache. (Note: "apachectl graceful" is not enough to correct this, it needs a real restart of the process.)
I do that regularly.
Longer term solution is to move out of mod_python (mod_wsgi likely, going to CGI will create other performance problems), or to transition the stuff there to a more beefy server.
There is also Trac. Between Trac and mod_python the load on the machine goes up to 20+ at times. I spent some time trying to figure out a move of the current machine to Amazon to a beefier instance (and I am not opposed to it but there is a lot of cruft and strange setup on it as well as the fact that it is not really clear what is what and why it is running) but this would be a case of solving a problem by throwing more hardware at it. If everyone is OK with that, fine. I personally think moving away from Trac (which IMHO is bloated and awkward in addition to having a very weird way of being administered) would be a better idea. My $0.02 Ognen
01.09.2012 00:08, Ognen Duzlevski kirjoitti: [clip]
I personally think moving away from Trac (which IMHO is bloated and awkward in addition to having a very weird way of being administered) would be a better idea.
Yes, moving away from Trac is planned, both for Numpy and Scipy. Also agreed on the point of clumsy administration. This however leaves the other services still on the machine, although after dropping Trac, the juice probably is enough for them. -- Pauli Virtanen
participants (3)
-
Ognen Duzlevski -
Ondřej Čertík -
Pauli Virtanen