From post at volker-wysk.de Wed Nov 1 16:02:47 2017
From: post at volker-wysk.de (Volker Wysk)
Date: Wed, 01 Nov 2017 21:02:47 +0100
Subject: [moin-user] MoinMoin very slow
Message-ID: <10942129.O9o76ZdvQC@desktop>
Hello!
My MoinMoin has become very slow. It takes some 30 seconds to save a (long) page.
It's just one user (me).
It doesn't make a difference if i'ts the text editor or the GUI.
Any hints?
Volker
From paul at boddie.org.uk Wed Nov 1 16:49:49 2017
From: paul at boddie.org.uk (Paul Boddie)
Date: Wed, 1 Nov 2017 21:49:49 +0100
Subject: [moin-user] MoinMoin very slow
In-Reply-To: <10942129.O9o76ZdvQC@desktop>
References: <10942129.O9o76ZdvQC@desktop>
Message-ID: <201711012149.49335.paul@boddie.org.uk>
On Wednesday 1. November 2017 21.02.47 Volker Wysk wrote:
>
> My MoinMoin has become very slow. It takes some 30 seconds to save a (long)
> page.
>
> It's just one user (me).
>
> It doesn't make a difference if i'ts the text editor or the GUI.
>
> Any hints?
The show_timings setting might provide some more detail about where Moin is
spending its time:
https://moinmo.in/HelpOnConfiguration#style
Other than that, some kind of idea of the environment Moin is operating in
might be useful...
Publicly accessible or inaccessible?
Lots of processes on the machine or only a few?
Local or network filesystem?
Nameserver usage: are the Web server and Moin doing reverse DNS lookups?
Try show_timings first of all, though.
Paul
From post at volker-wysk.de Wed Nov 1 18:44:28 2017
From: post at volker-wysk.de (Volker Wysk)
Date: Wed, 01 Nov 2017 23:44:28 +0100
Subject: [moin-user] MoinMoin very slow
In-Reply-To: <201711012149.49335.paul@boddie.org.uk>
References: <10942129.O9o76ZdvQC@desktop>
<201711012149.49335.paul@boddie.org.uk>
Message-ID: <2111587.7j9o1Vg0Pa@desktop>
Am Mittwoch, 1. November 2017, 21:49:49 CET schrieb Paul Boddie:
> On Wednesday 1. November 2017 21.02.47 Volker Wysk wrote:
> >
> > My MoinMoin has become very slow. It takes some 30 seconds to save a (long)
> > page.
> >
> > It's just one user (me).
> >
> > It doesn't make a difference if i'ts the text editor or the GUI.
> >
> > Any hints?
>
> The show_timings setting might provide some more detail about where Moin is
> spending its time:
>
> https://moinmo.in/HelpOnConfiguration#style
This looks like this:
Page.execute = 20.668s
i18n_init = 0.299s
init = 0.370s
loadLanguage = 0.115s
load_multi_cfg = 0.274s
run = 41.985s
send_page = 41.809s
send_page_content = 41.156s
send_page_content|1 = 20.578s
send_page|1 = 20.578s
total = 42.354s
> Other than that, some kind of idea of the environment Moin is operating in
> might be useful...
Kubuntu 16.04, Apache2, ...
> Publicly accessible or inaccessible?
inaccessible, one user only
> Lots of processes on the machine or only a few?
This process runs alle the time with 100% CPU:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
8509 www-data 20 0 106144 49460 9340 R 100.0 0.6 0:04.94 python
> Local or network filesystem?
Local.
> Nameserver usage: are the Web server and Moin doing reverse DNS lookups?
How to find this out?
> Try show_timings first of all, though.
See above.
And: It runs much faster for smaller pages.
Thnx
Volker
From paul at boddie.org.uk Wed Nov 1 19:16:05 2017
From: paul at boddie.org.uk (Paul Boddie)
Date: Thu, 2 Nov 2017 00:16:05 +0100
Subject: [moin-user] MoinMoin very slow
In-Reply-To: <2111587.7j9o1Vg0Pa@desktop>
References: <10942129.O9o76ZdvQC@desktop>
<201711012149.49335.paul@boddie.org.uk> <2111587.7j9o1Vg0Pa@desktop>
Message-ID: <201711020016.06672.paul@boddie.org.uk>
On Wednesday 1. November 2017 23.44.28 Volker Wysk wrote:
>
> This looks like this:
>
> Page.execute = 20.668s
> i18n_init = 0.299s
> init = 0.370s
> loadLanguage = 0.115s
> load_multi_cfg = 0.274s
> run = 41.985s
> send_page = 41.809s
> send_page_content = 41.156s
> send_page_content|1 = 20.578s
> send_page|1 = 20.578s
> total = 42.354s
So, working through this without any recent knowledge or experience myself, I
see that the MoinMoin.Page.Page.send_page_content method is the thing using
all the time. It obtains a parser and then either gets a cached version of the
page or formats a new version.
Is there anything special about the page? Anything like macros being used, for
instance.
> > Other than that, some kind of idea of the environment Moin is operating
> > in might be useful...
>
> Kubuntu 16.04, Apache2, ...
>
> > Publicly accessible or inaccessible?
>
> inaccessible, one user only
>
> > Lots of processes on the machine or only a few?
>
> This process runs alle the time with 100% CPU:
>
> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
> 8509 www-data 20 0 106144 49460 9340 R 100.0 0.6 0:04.94 python
This indicates that it is presumably quite busy and not necessarily waiting
for input/output, so the nameserver suggestion is probably uninteresting.
> > Local or network filesystem?
>
> Local.
>
> > Nameserver usage: are the Web server and Moin doing reverse DNS lookups?
>
> How to find this out?
I suppose the easiest way is to just look at your Apache and Moin logs and see
if you have numeric IP addresses or ones with actual names. But I doubt that
this would cause the time to be consumed in send_page_content, so we can
perhaps rule this out as a cause.
> > Try show_timings first of all, though.
>
> See above.
>
> And: It runs much faster for smaller pages.
I do wonder about "send_page_content|1" which might well be a recursive call
generating a subpage, perhaps for a table of contents. The way that the
combined time is approximately double the individual times might suggest that
the cache isn't working properly. But 20s page generation times are not
exactly normal, either.
It's been a long time since I troubleshooted a Moin performance problem like
this, and then I think it was probably related to the low-performance, non-
Xapian search function, not page loading.
Paul
From post at volker-wysk.de Thu Nov 2 03:29:13 2017
From: post at volker-wysk.de (Volker Wysk)
Date: Thu, 02 Nov 2017 08:29:13 +0100
Subject: [moin-user] MoinMoin very slow
In-Reply-To: <201711020016.06672.paul@boddie.org.uk>
References: <10942129.O9o76ZdvQC@desktop> <2111587.7j9o1Vg0Pa@desktop>
<201711020016.06672.paul@boddie.org.uk>
Message-ID: <2046011.4oLZGMOQcC@desktop>
Am Donnerstag, 2. November 2017, 00:16:05 CET schrieb Paul Boddie:
> On Wednesday 1. November 2017 23.44.28 Volker Wysk wrote:
> >
> > This looks like this:
> >
> > Page.execute = 20.668s
> > i18n_init = 0.299s
> > init = 0.370s
> > loadLanguage = 0.115s
> > load_multi_cfg = 0.274s
> > run = 41.985s
> > send_page = 41.809s
> > send_page_content = 41.156s
> > send_page_content|1 = 20.578s
> > send_page|1 = 20.578s
> > total = 42.354s
>
> So, working through this without any recent knowledge or experience myself, I
> see that the MoinMoin.Page.Page.send_page_content method is the thing using
> all the time. It obtains a parser and then either gets a cached version of the
> page or formats a new version.
>
> Is there anything special about the page? Anything like macros being used, for
> instance.
I'm using some <
> macros, and a "#!highlight" parser. Also using
<>. Disabling the TOC and the parser didn't speed things up.
> > > Other than that, some kind of idea of the environment Moin is operating
> > > in might be useful...
> >
> > Kubuntu 16.04, Apache2, ...
> >
> > > Publicly accessible or inaccessible?
> >
> > inaccessible, one user only
> >
> > > Lots of processes on the machine or only a few?
> >
> > This process runs alle the time with 100% CPU:
> >
> > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
> > 8509 www-data 20 0 106144 49460 9340 R 100.0 0.6 0:04.94 python
>
> This indicates that it is presumably quite busy and not necessarily waiting
> for input/output, so the nameserver suggestion is probably uninteresting.
I've tried vwysk.now-dns.net (my dynamic DNS-Name), localhost and
127.0.0.1. No luck. All slow.
>
> > > Local or network filesystem?
> >
> > Local.
> >
> > > Nameserver usage: are the Web server and Moin doing reverse DNS lookups?
> >
> > How to find this out?
>
> I suppose the easiest way is to just look at your Apache and Moin logs and see
> if you have numeric IP addresses or ones with actual names. But I doubt that
> this would cause the time to be consumed in send_page_content, so we can
> perhaps rule this out as a cause.
>
> > > Try show_timings first of all, though.
> >
> > See above.
> >
> > And: It runs much faster for smaller pages.
>
> I do wonder about "send_page_content|1" which might well be a recursive call
> generating a subpage, perhaps for a table of contents. The way that the
> combined time is approximately double the individual times might suggest that
> the cache isn't working properly. But 20s page generation times are not
> exactly normal, either.
A special cache for MoinMoin? How do you configure it? I might not have
installed it, because I thought I don't need it.
> It's been a long time since I troubleshooted a Moin performance problem like
> this, and then I think it was probably related to the low-performance, non-
> Xapian search function, not page loading.
Regards,
Volker
From paul at boddie.org.uk Thu Nov 2 08:11:36 2017
From: paul at boddie.org.uk (Paul Boddie)
Date: Thu, 2 Nov 2017 13:11:36 +0100
Subject: [moin-user] MoinMoin very slow
In-Reply-To: <2046011.4oLZGMOQcC@desktop>
References: <10942129.O9o76ZdvQC@desktop>
<201711020016.06672.paul@boddie.org.uk> <2046011.4oLZGMOQcC@desktop>
Message-ID: <201711021311.38509.paul@boddie.org.uk>
On Thursday 2. November 2017 08.29.13 Volker Wysk wrote:
> Am Donnerstag, 2. November 2017, 00:16:05 CET schrieb Paul Boddie:
> >
> > Is there anything special about the page? Anything like macros being
> > used, for instance.
>
> I'm using some <
> macros, and a "#!highlight" parser. Also using
> <>. Disabling the TOC and the parser didn't speed things
> up.
OK. From what I can gather, I guess that the highlight parser wouldn't affect
performance that much anyway.
[...]
> > I do wonder about "send_page_content|1" which might well be a recursive
> > call generating a subpage, perhaps for a table of contents. The way that
> > the combined time is approximately double the individual times might
> > suggest that the cache isn't working properly. But 20s page generation
> > times are not exactly normal, either.
>
> A special cache for MoinMoin? How do you configure it? I might not have
> installed it, because I thought I don't need it.
No, the cache is built into MoinMoin, so it should just work. However, it
seems to be a constant source of problems, usually producing errors that are
often dealt with using "moin maint cleancache".
I imagine that we might need to dig deeper to see where Moin is spending all
its time. Did you look at the following page, by the way...?
https://moinmo.in/HowTo/Tune%20Performance
Paul
From post at volker-wysk.de Thu Nov 2 09:28:17 2017
From: post at volker-wysk.de (Volker Wysk)
Date: Thu, 02 Nov 2017 14:28:17 +0100
Subject: [moin-user] MoinMoin very slow
In-Reply-To: <201711021311.38509.paul@boddie.org.uk>
References: <10942129.O9o76ZdvQC@desktop> <2046011.4oLZGMOQcC@desktop>
<201711021311.38509.paul@boddie.org.uk>
Message-ID: <7403384.JQaWJBRKkV@desktop>
Am Donnerstag, 2. November 2017, 13:11:36 CET schrieb Paul Boddie:
> However, it
> seems to be a constant source of problems, usually producing errors that are
> often dealt with using "moin maint cleancache".
This produces an error:
desktop ~ % moin maint cleancache
2017-11-02 13:54:01,964 INFO MoinMoin.log:151 using logging configuration read from built-in fallback in MoinMoin.log module
2017-11-02 13:54:01,964 INFO MoinMoin.log:157 Running MoinMoin 1.9.9 release code from /usr/local/lib/python2.7/dist-packages/MoinMoin
2017-11-02 13:54:02,361 ERROR MoinMoin.config.multiconfig:129 Could not import.
Traceback (most recent call last):
File "/usr/local/lib/python2.7/dist-packages/MoinMoin/config/multiconfig.py", line 123, in _makeConfig
module, mtime = _importConfigModule(name)
File "/usr/local/lib/python2.7/dist-packages/MoinMoin/config/multiconfig.py", line 48, in _importConfigModule
module = __import__(name, globals(), {})
ImportError: No module named wikiconfig
Traceback (most recent call last):
(...)
I'm configuring everything in /usr/local/share/moin/config/wikiconfig.py.
What is this "multiconfig.py" thing ...? I don't have it.
Chees
Volker
From post at volker-wysk.de Thu Nov 2 10:58:04 2017
From: post at volker-wysk.de (Volker Wysk)
Date: Thu, 02 Nov 2017 15:58:04 +0100
Subject: [moin-user] MoinMoin very slow
In-Reply-To: <201711021311.38509.paul@boddie.org.uk>
References: <10942129.O9o76ZdvQC@desktop> <2046011.4oLZGMOQcC@desktop>
<201711021311.38509.paul@boddie.org.uk>
Message-ID: <2783415.eSmmzF7rRR@desktop>
Am Donnerstag, 2. November 2017, 13:11:36 CET schrieb Paul Boddie:
> I imagine that we might need to dig deeper to see where Moin is spending all
> its time. Did you look at the following page, by the way...?
>
> https://moinmo.in/HowTo/Tune%20Performance
Now I have.
Can it because of using CGI instead of WSGI?
I've also tried "log_reverse_dns_lookups = False", but it's still slow.
Volker
From paul at boddie.org.uk Thu Nov 2 12:42:20 2017
From: paul at boddie.org.uk (Paul Boddie)
Date: Thu, 2 Nov 2017 17:42:20 +0100
Subject: [moin-user] MoinMoin very slow
In-Reply-To: <2783415.eSmmzF7rRR@desktop>
References: <10942129.O9o76ZdvQC@desktop>
<201711021311.38509.paul@boddie.org.uk> <2783415.eSmmzF7rRR@desktop>
Message-ID: <201711021742.21424.paul@boddie.org.uk>
On Thursday 2. November 2017 15.58.04 Volker Wysk wrote:
> Am Donnerstag, 2. November 2017, 13:11:36 CET schrieb Paul Boddie:
> > I imagine that we might need to dig deeper to see where Moin is spending
> > all its time. Did you look at the following page, by the way...?
> >
> > https://moinmo.in/HowTo/Tune%20Performance
>
> Now I have.
>
> Can it because of using CGI instead of WSGI?
No, not for one page load being slow, as in this case. Although Moin probably
gets some benefit having processes active rather than needing to have them
spawned when a request arrives, it isn't like it is really slow because it
needs to have a lot of expensively-computed content sitting in some buffer
ready for subsequent requests.
In other words, Moin isn't really one of those Web applications that is so
slow that it needs to permanently sit there taking up lots of memory, like a
Java application server or something.
> I've also tried "log_reverse_dns_lookups = False", but it's still slow.
OK. Good to have that confirmed, anyway.
Was this performance issue something that just started to happen, or is it
that you finally made a big page and then saw that it was slow?
Looking at your statistics again, I see that part of the block of time being
consumed is this:
Page.execute = 20.668s
Now, this is supposedly concerned with just delivering the cached content
(either generated previously or for this request). But I wonder whether it
should really take very long given that what it should be doing is executing a
compiled representation of the content. For me, it takes hardly any time at
all within all the time used by a request.
I'm wondering if there's a convenient way of profiling Moin. The wiki has some
old pages about profiling, but I see that in the CGI script, there's a way of
generating a profile:
class Config(CgiConfig):
# Server name - used to create .prof files
name = 'moin'
# Properties
# Allow overriding any request property by the value defined in
# this dict e.g properties = {'script_name': '/mywiki'}.
## properties = {}
# Hotshot profile (default commented)
## hotshotProfile = name + '.prof'
If you change the last part to something like this...
hotshotProfile = "/tmp/moin.prof"
...this will hopefully generate profiling information (without complaining
about permissions), and it can be converted to readable information as
follows:
hotshot2calltree -o /tmp/moin.tree /tmp/moin.prof
We can probably even use other tools to visualise this nicely:
kcachegrind /tmp/moin.tree
Although my brief tests don't provide so much useful information, maybe there
is something more interesting in any data you can generate.
Paul
From post at volker-wysk.de Thu Nov 2 13:13:23 2017
From: post at volker-wysk.de (Volker Wysk)
Date: Thu, 02 Nov 2017 18:13:23 +0100
Subject: [moin-user] MoinMoin very slow
In-Reply-To: <201711021742.21424.paul@boddie.org.uk>
References: <10942129.O9o76ZdvQC@desktop> <2783415.eSmmzF7rRR@desktop>
<201711021742.21424.paul@boddie.org.uk>
Message-ID: <13482194.bJLXHlSMRD@desktop>
Am Donnerstag, 2. November 2017, 17:42:20 CET schrieb Paul Boddie:
> Was this performance issue something that just started to happen, or is it
> that you finally made a big page and then saw that it was slow?
It just started at a point in time. I've had this very page with no such issues.
> Looking at your statistics again, I see that part of the block of time being
> consumed is this:
>
> Page.execute = 20.668s
>
> Now, this is supposedly concerned with just delivering the cached content
> (either generated previously or for this request). But I wonder whether it
> should really take very long given that what it should be doing is executing a
> compiled representation of the content. For me, it takes hardly any time at
> all within all the time used by a request.
>
> I'm wondering if there's a convenient way of profiling Moin. The wiki has some
> old pages about profiling, but I see that in the CGI script, there's a way of
> generating a profile:
>
> class Config(CgiConfig):
> # Server name - used to create .prof files
> name = 'moin'
>
> # Properties
> # Allow overriding any request property by the value defined in
> # this dict e.g properties = {'script_name': '/mywiki'}.
> ## properties = {}
>
> # Hotshot profile (default commented)
> ## hotshotProfile = name + '.prof'
>
> If you change the last part to something like this...
>
> hotshotProfile = "/tmp/moin.prof"
>
> ...this will hopefully generate profiling information (without complaining
> about permissions),
No luck on my side. Just to be sure: you mean adding the class definition
above to /usr/local/share/moin/server/moin.cgi, and doing a "service
apache2 restart". There was no "class Config(CgiConfig)" in there, before.
> and it can be converted to readable information as
> follows:
>
> hotshot2calltree -o /tmp/moin.tree /tmp/moin.prof
>
> We can probably even use other tools to visualise this nicely:
>
> kcachegrind /tmp/moin.tree
>
> Although my brief tests don't provide so much useful information, maybe there
> is something more interesting in any data you can generate.
>
Volker
From post at volker-wysk.de Thu Nov 2 13:22:04 2017
From: post at volker-wysk.de (Volker Wysk)
Date: Thu, 02 Nov 2017 18:22:04 +0100
Subject: [moin-user] MoinMoin very slow
In-Reply-To: <201711021742.21424.paul@boddie.org.uk>
References: <10942129.O9o76ZdvQC@desktop> <2783415.eSmmzF7rRR@desktop>
<201711021742.21424.paul@boddie.org.uk>
Message-ID: <13727271.YzzQCT0H0c@desktop>
Hi
I've had a closer look at the page's source code. There are some formatted
sections ({{{...}}}), some <
>, but nothing suspicious...
Volker
From paul at boddie.org.uk Thu Nov 2 13:35:06 2017
From: paul at boddie.org.uk (Paul Boddie)
Date: Thu, 2 Nov 2017 18:35:06 +0100
Subject: [moin-user] MoinMoin very slow
In-Reply-To: <13482194.bJLXHlSMRD@desktop>
References: <10942129.O9o76ZdvQC@desktop>
<201711021742.21424.paul@boddie.org.uk> <13482194.bJLXHlSMRD@desktop>
Message-ID: <201711021835.07205.paul@boddie.org.uk>
On Thursday 2. November 2017 18.13.23 Volker Wysk wrote:
>
> No luck on my side. Just to be sure: you mean adding the class definition
> above to /usr/local/share/moin/server/moin.cgi, and doing a "service
> apache2 restart". There was no "class Config(CgiConfig)" in there, before.
Sorry, I guess I was looking at a Moin 1.8 instance here, not 1.9.
In 1.9, there are various profilers, but they need to be plugged into the WSGI
pipeline (even if you're using CGI, Moin uses WSGI internally), and I've never
done this myself.
Maybe someone else has some experience with this or any of the other issues
raised here.
Paul
From post at volker-wysk.de Thu Nov 2 13:43:43 2017
From: post at volker-wysk.de (Volker Wysk)
Date: Thu, 02 Nov 2017 18:43:43 +0100
Subject: [moin-user] MoinMoin very slow
In-Reply-To:
References: <10942129.O9o76ZdvQC@desktop> <13482194.bJLXHlSMRD@desktop>
Message-ID: <1864701.xMRqLy2Rhn@desktop>
Am Donnerstag, 2. November 2017, 13:20:48 CET schrieb Chris Freemesser:
> On 11/02/2017 01:13 PM, Volker Wysk wrote:
>
> > It just started at a point in time. I've had this very page with no such issues.
> I'm sorry that I've not been reading this thread very closely, but what
> are the chances that it's not a problem with Moin itself, but that you
> have a problem with your hard drive and repeated attempts to read a bad
> sector are the reason you're seeing a delay?
When I go to the page's directory in the moinmoin file-based database,
and read the page, it works well:
cd /usr/local/share/moin/data/pages/Rechner(2f)Einrichtung(2f)SSD/revisions
cat 00000128 > /dev/null
What else, and how else should be checked for problems with the hard drive...?
I've bought that hard drive at the end of 2015. I don't think, it should fail so
soon.
Regards
Volker
From post at volker-wysk.de Thu Nov 2 13:50:03 2017
From: post at volker-wysk.de (Volker Wysk)
Date: Thu, 02 Nov 2017 18:50:03 +0100
Subject: [moin-user] MoinMoin very slow
In-Reply-To: <201711021835.07205.paul@boddie.org.uk>
References: <10942129.O9o76ZdvQC@desktop> <13482194.bJLXHlSMRD@desktop>
<201711021835.07205.paul@boddie.org.uk>
Message-ID: <2150673.NGskJkD61r@desktop>
Am Donnerstag, 2. November 2017, 18:35:06 CET schrieb Paul Boddie:
> On Thursday 2. November 2017 18.13.23 Volker Wysk wrote:
> >
> > No luck on my side. Just to be sure: you mean adding the class definition
> > above to /usr/local/share/moin/server/moin.cgi, and doing a "service
> > apache2 restart". There was no "class Config(CgiConfig)" in there, before.
>
> Sorry, I guess I was looking at a Moin 1.8 instance here, not 1.9.
>
> In 1.9, there are various profilers, but they need to be plugged into the WSGI
> pipeline (even if you're using CGI, Moin uses WSGI internally), and I've never
> done this myself.
>
> Maybe someone else has some experience with this or any of the other issues
> raised here.
What about that failing "moin maint cleancache" command? See my message
of 14:28:17.
Volker
From paul at boddie.org.uk Thu Nov 2 13:54:48 2017
From: paul at boddie.org.uk (Paul Boddie)
Date: Thu, 2 Nov 2017 18:54:48 +0100
Subject: [moin-user] MoinMoin very slow
In-Reply-To: <1864701.xMRqLy2Rhn@desktop>
References: <10942129.O9o76ZdvQC@desktop>
<1864701.xMRqLy2Rhn@desktop>
Message-ID: <201711021854.48315.paul@boddie.org.uk>
On Thursday 2. November 2017 18.43.43 Volker Wysk wrote:
>
> What else, and how else should be checked for problems with the hard
> drive...?
>
> I've bought that hard drive at the end of 2015. I don't think, it should
> fail so soon.
Hard drives can fail within a year if they are faulty. I had this kind of
experience with a Western Digital Caviar Green drive a few years back
(separate from the pathological head parking behaviour that wasn't advertised
by the manufacturer because the Windows driver code was dealing with it, but
where everyone else was on their own). Fortunately, the failure was relatively
graceful.
Try smartctl to see what the drive controller thinks:
sudo smartctl --all /dev/sda
Here, /dev/sda is the SATA device of interest. Use lsblk to see details of
devices.
Certainly, Chris is right in that hard disk failure can cause all sorts of bad
blocking behaviour, although I'm not sure whether it would leave processes
running at 100% CPU.
Paul
From post at volker-wysk.de Thu Nov 2 14:21:45 2017
From: post at volker-wysk.de (Volker Wysk)
Date: Thu, 02 Nov 2017 19:21:45 +0100
Subject: [moin-user] MoinMoin very slow
In-Reply-To: <201711021854.48315.paul@boddie.org.uk>
References: <10942129.O9o76ZdvQC@desktop> <1864701.xMRqLy2Rhn@desktop>
<201711021854.48315.paul@boddie.org.uk>
Message-ID: <4279861.pR5KubLXJ9@desktop>
Am Donnerstag, 2. November 2017, 18:54:48 CET schrieb Paul Boddie:
> Try smartctl to see what the drive controller thinks:
>
> sudo smartctl --all /dev/sda
>
> Here, /dev/sda is the SATA device of interest. Use lsblk to see details of
> devices.
It's a long output, but nothing which looks particiularly suspicious.
SMART Error Log Version: 1
No Errors Logged
---------snip---------
smartctl 6.5 2016-01-24 r4214 [x86_64-linux-4.4.0-97-generic] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF INFORMATION SECTION ===
Model Family: Western Digital Red
Device Model: WDC WD40EFRX-68WT0N0
Serial Number: WD-WCC4E7LACSDS
LU WWN Device Id: 5 0014ee 20b871f92
Firmware Version: 82.00A82
User Capacity: 4.000.787.030.016 bytes [4,00 TB]
Sector Sizes: 512 bytes logical, 4096 bytes physical
Rotation Rate: 5400 rpm
Device is: In smartctl database [for details use: -P show]
ATA Version is: ACS-2 (minor revision not indicated)
SATA Version is: SATA 3.0, 6.0 Gb/s (current: 3.0 Gb/s)
Local Time is: Thu Nov 2 19:17:30 2017 CET
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
General SMART Values:
Offline data collection status: (0x00) Offline data collection activity
was never started.
Auto Offline Data Collection: Disabled.
Self-test execution status: ( 0) The previous self-test routine completed
without error or no self-test has ever
been run.
Total time to complete Offline
data collection: (52380) seconds.
Offline data collection
capabilities: (0x7b) SMART execute Offline immediate.
Auto Offline data collection on/off support.
Suspend Offline collection upon new
command.
Offline surface scan supported.
Self-test supported.
Conveyance Self-test supported.
Selective Self-test supported.
SMART capabilities: (0x0003) Saves SMART data before entering
power-saving mode.
Supports SMART auto save timer.
Error logging capability: (0x01) Error logging supported.
General Purpose Logging supported.
Short self-test routine
recommended polling time: ( 2) minutes.
Extended self-test routine
recommended polling time: ( 524) minutes.
Conveyance self-test routine
recommended polling time: ( 5) minutes.
SCT capabilities: (0x703d) SCT Status supported.
SCT Error Recovery Control supported.
SCT Feature Control supported.
SCT Data Table supported.
SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x002f 200 200 051 Pre-fail Always - 0
3 Spin_Up_Time 0x0027 201 179 021 Pre-fail Always - 6916
4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 133
5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0
7 Seek_Error_Rate 0x002e 200 200 000 Old_age Always - 0
9 Power_On_Hours 0x0032 078 078 000 Old_age Always - 16609
10 Spin_Retry_Count 0x0032 100 100 000 Old_age Always - 0
11 Calibration_Retry_Count 0x0032 100 100 000 Old_age Always - 0
12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 131
192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always - 14
193 Load_Cycle_Count 0x0032 200 200 000 Old_age Always - 773
194 Temperature_Celsius 0x0022 105 097 000 Old_age Always - 47
196 Reallocated_Event_Count 0x0032 200 200 000 Old_age Always - 0
197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always - 0
198 Offline_Uncorrectable 0x0030 100 253 000 Old_age Offline - 0
199 UDMA_CRC_Error_Count 0x0032 200 200 000 Old_age Always - 0
200 Multi_Zone_Error_Rate 0x0008 100 253 000 Old_age Offline - 0
SMART Error Log Version: 1
No Errors Logged
SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
# 1 Short offline Completed without error 00% 15625 -
SMART Selective self-test log data structure revision number 1
SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS
1 0 0 Not_testing
2 0 0 Not_testing
3 0 0 Not_testing
4 0 0 Not_testing
5 0 0 Not_testing
Selective self-test flags (0x0):
After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.
---------snip---------
Bye
Volker
From cfreemes at ur.rochester.edu Thu Nov 2 13:52:43 2017
From: cfreemes at ur.rochester.edu (Chris Freemesser)
Date: Thu, 2 Nov 2017 13:52:43 -0400
Subject: [moin-user] MoinMoin very slow
In-Reply-To: <1864701.xMRqLy2Rhn@desktop>
References: <10942129.O9o76ZdvQC@desktop> <13482194.bJLXHlSMRD@desktop>
<1864701.xMRqLy2Rhn@desktop>
Message-ID:
On 11/02/2017 01:43 PM, Volker Wysk wrote:
> What else, and how else should be checked for problems with the hard drive...?
Depends on what operating system you're running, but something like
'chkdsk' for Windows or 'e2fsck' for Linux would be the tool to use.
> I've bought that hard drive at the end of 2015. I don't think, it should fail so
> soon.
Never assume something like that...working in IT for the last 31 years
(ugh, lol) has told me that hard drives can last anywhere between 10
minutes or 10 years after you take them out of the box.
Chris
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Chris Freemesser, Systems Administrator
Dept. of Brain & Cognitive Sciences +
The Center for Visual Science
University of Rochester
255 Meliora Hall
585-275-0786
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
From post at volker-wysk.de Thu Nov 2 14:29:40 2017
From: post at volker-wysk.de (Volker Wysk)
Date: Thu, 02 Nov 2017 19:29:40 +0100
Subject: [moin-user] MoinMoin very slow
In-Reply-To:
References: <10942129.O9o76ZdvQC@desktop> <1864701.xMRqLy2Rhn@desktop>
Message-ID: <5375651.y0MKLJsVfL@desktop>
Hi
I've copied the whole page, so new places on the hard disk should contain it. Same problem.
Am Donnerstag, 2. November 2017, 13:52:43 CET schrieb Chris Freemesser:
> On 11/02/2017 01:43 PM, Volker Wysk wrote:
>
> > What else, and how else should be checked for problems with the hard drive...?
>
> Depends on what operating system you're running, but something like
> 'chkdsk' for Windows or 'e2fsck' for Linux would be the tool to use.
Oh, I need to install a Kubuntu on an USB stick, so I can do that.
> > I've bought that hard drive at the end of 2015. I don't think, it should fail so
> > soon.
>
> Never assume something like that...working in IT for the last 31 years
> (ugh, lol) has told me that hard drives can last anywhere between 10
> minutes or 10 years after you take them out of the box.
:-(
Volker
From cfreemes at ur.rochester.edu Thu Nov 2 13:20:48 2017
From: cfreemes at ur.rochester.edu (Chris Freemesser)
Date: Thu, 2 Nov 2017 13:20:48 -0400
Subject: [moin-user] MoinMoin very slow
In-Reply-To: <13482194.bJLXHlSMRD@desktop>
References: <10942129.O9o76ZdvQC@desktop> <2783415.eSmmzF7rRR@desktop>
<201711021742.21424.paul@boddie.org.uk> <13482194.bJLXHlSMRD@desktop>
Message-ID:
On 11/02/2017 01:13 PM, Volker Wysk wrote:
> It just started at a point in time. I've had this very page with no such issues.
I'm sorry that I've not been reading this thread very closely, but what
are the chances that it's not a problem with Moin itself, but that you
have a problem with your hard drive and repeated attempts to read a bad
sector are the reason you're seeing a delay?
Chris
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Chris Freemesser, Systems Administrator
Dept. of Brain & Cognitive Sciences +
The Center for Visual Science
University of Rochester
255 Meliora Hall
585-275-0786
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
From post at volker-wysk.de Thu Nov 2 16:54:44 2017
From: post at volker-wysk.de (Volker Wysk)
Date: Thu, 02 Nov 2017 21:54:44 +0100
Subject: [moin-user] MoinMoin very slow
In-Reply-To: <10942129.O9o76ZdvQC@desktop>
References: <10942129.O9o76ZdvQC@desktop>
Message-ID: <3449944.O7kVYLoe2W@desktop>
Hi!
I've looked at the source code of the offending page again, und found what
was the cause of the very small display of the page: There was a large
block (all in one line) of giggerish, which looked like this:
"" & quot; & amp; quot; & amp; amp; quot; & amp; amp; amp; quot; & amp; amp; amp; amp; quot; & amp; amp; amp; amp; amp; quot; & amp; amp; amp; amp; amp; amp; quot; & amp; amp; amp; amp; amp; amp; amp; quot; & amp; amp; amp; amp; amp;"
I have no idea of why I haven't noticed earlier.
Removing this, solved one problem. The second is: Where does this come from? Could be a bug in the GUI editor.
Bye and thanks,
Volker
From paul at boddie.org.uk Thu Nov 2 17:04:56 2017
From: paul at boddie.org.uk (Paul Boddie)
Date: Thu, 2 Nov 2017 22:04:56 +0100
Subject: [moin-user] MoinMoin very slow
In-Reply-To: <3449944.O7kVYLoe2W@desktop>
References: <10942129.O9o76ZdvQC@desktop> <3449944.O7kVYLoe2W@desktop>
Message-ID: <201711022204.57119.paul@boddie.org.uk>
On Thursday 2. November 2017 21.54.44 Volker Wysk wrote:
> Hi!
>
> I've looked at the source code of the offending page again, und found what
> was the cause of the very small display of the page: There was a large
> block (all in one line) of giggerish, which looked like this:
>
> "" & quot; & amp; quot; & amp; amp; quot; &
> amp; amp; amp; quot; & amp; amp; amp; amp; quot;
> & amp; amp; amp; amp; amp; quot; & amp;
> amp; amp; amp; amp; amp; quot; & amp; amp;
> amp; amp; amp; amp; amp; quot; &
> amp; amp; amp; amp; amp;"
>
> I have no idea of why I haven't noticed earlier.
>
> Removing this, solved one problem. The second is: Where does this come
> from? Could be a bug in the GUI editor.
It may well have come from the GUI editor which probably gets even less
attention than it used to. Once upon a time I had thought to replace it with
something else - someone mentioned the whole contenteditable thing where the
browser takes care of the editing functionality - but I never got round to it.
Paul
From paul at boddie.org.uk Thu Nov 2 17:11:19 2017
From: paul at boddie.org.uk (Paul Boddie)
Date: Thu, 2 Nov 2017 22:11:19 +0100
Subject: [moin-user] MoinMoin very slow
In-Reply-To: <4279861.pR5KubLXJ9@desktop>
References: <10942129.O9o76ZdvQC@desktop>
<201711021854.48315.paul@boddie.org.uk> <4279861.pR5KubLXJ9@desktop>
Message-ID: <201711022211.20245.paul@boddie.org.uk>
On Thursday 2. November 2017 19.21.45 Volker Wysk wrote:
> Am Donnerstag, 2. November 2017, 18:54:48 CET schrieb Paul Boddie:
> > Try smartctl to see what the drive controller thinks:
> >
> > sudo smartctl --all /dev/sda
> >
> > Here, /dev/sda is the SATA device of interest. Use lsblk to see details
> > of devices.
>
> It's a long output, but nothing which looks particiularly suspicious.
I agree. The testing section doesn't have much in it...
> SMART Self-test log structure revision number 1
> Num Test_Description Status Remaining LifeTime(hours)
> LBA_of_first_error # 1 Short offline Completed without error
> 00% 15625 -
>
> SMART Selective self-test log data structure revision number 1
> SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS
> 1 0 0 Not_testing
> 2 0 0 Not_testing
> 3 0 0 Not_testing
> 4 0 0 Not_testing
> 5 0 0 Not_testing
Maybe a short test might be helpful to confirm a lack of problems. I think
this will do the trick, following the example given above:
sudo smartctl -t short /dev/sda
The drive information will be updated after a fairly short period to show the
test result.
Paul
P.S. I think it was Load_Cycle_Count that indicated the pathological WD Caviar
Green behaviour. Yours is at a healthy 773 whereas mine reached the hundreds
of thousands before I turned off the bad behaviour.
From post at volker-wysk.de Thu Nov 2 17:23:44 2017
From: post at volker-wysk.de (Volker Wysk)
Date: Thu, 02 Nov 2017 22:23:44 +0100
Subject: [moin-user] MoinMoin very slow
In-Reply-To: <201711022204.57119.paul@boddie.org.uk>
References: <10942129.O9o76ZdvQC@desktop> <3449944.O7kVYLoe2W@desktop>
<201711022204.57119.paul@boddie.org.uk>
Message-ID: <9680534.RV3atjvHLj@desktop>
Am Donnerstag, 2. November 2017, 22:04:56 CET schrieb Paul Boddie:
> On Thursday 2. November 2017 21.54.44 Volker Wysk wrote:
> > Removing this, solved one problem. The second is: Where does this come
> > from? Could be a bug in the GUI editor.
>
> It may well have come from the GUI editor which probably gets even less
> attention than it used to.
And there are some more issues...
> Once upon a time I had thought to replace it with
> something else - someone mentioned the whole contenteditable thing where the
> browser takes care of the editing functionality - but I never got round to it.
Keep hacking
Volker
From post at volker-wysk.de Mon Nov 13 07:33:08 2017
From: post at volker-wysk.de (Volker Wysk)
Date: Mon, 13 Nov 2017 13:33:08 +0100
Subject: [moin-user] "file://" links in wiki pages
Message-ID: <9700091.a8W70hacDW@desktop>
Hi!
"file://"-Links in Wikipages don't work. There is no response to clicking
one at all.
For instance: Create some file /tmp/hallo.txt, and link to it in a Moin
page:
[[file:///tmp/hallo.txt]]
Then the HTML page contains the following:
file:///tmp/hallo.txt
When this is isolated, on a page by itself, the link works fine. However,
if it occurs enclosed in the rest of the Moin HTML page, the link is dead.
It doesn't matter if you use "file:/" or "file:///".
Bye
Volker
From post at volker-wysk.de Mon Nov 13 08:13:23 2017
From: post at volker-wysk.de (Volker Wysk)
Date: Mon, 13 Nov 2017 14:13:23 +0100
Subject: [moin-user] "file://" links in wiki pages
In-Reply-To: <9700091.a8W70hacDW@desktop>
References: <9700091.a8W70hacDW@desktop>
Message-ID: <9284264.75apfn2clC@desktop>
Am Montag, 13. November 2017, 13:33:08 CET schrieb Volker Wysk:
> When this is isolated, on a page by itself, the link works fine. However,
> if it occurs enclosed in the rest of the Moin HTML page, the link is dead.
Might this be for securtiy? "file://" links don't make much sense in a
multi user/multi machine environment... You need to upload the link target,
such that it becomes an attachment, which can be linked.
Be it as it may, a message would be good, when clicking on a "file://"
link, and such aren't supported.
Volker
From lists at hcf.yourweb.de Sat Nov 25 08:37:32 2017
From: lists at hcf.yourweb.de (lists at hcf.yourweb.de)
Date: Sat, 25 Nov 2017 14:37:32 +0100 (CET)
Subject: [moin-user] =?utf-8?b?fHw8dGFibGVjbGFzcz0i4oCmIj4gcHJvY2Vzc2lu?=
=?utf-8?q?g_broken_in_Moin_1=2E9=2E9?=
Message-ID: <1283338094.251949.1511617052336@ox.hosteurope.de>
I found a bug in Moin 1.9.9, but my account for the moinmo.in wiki has been deleted and I cannot register a new account as I don't know the magic password. So I am posting this here and hope some developer sees this. :)
MoinMoin-Wiki Markup Source:
|| '''Table Header''' ||
||