Today (23 days later) there are 128 hits in dewiki_p (6 additional wrong pairs), 78 in frwiki_p (2 fewer), still none in eswiki_p, still 25 in itwiki_p.

This is already implemented. Closing Task

From my side (s51412__data) it is done. Thanks.

From the few words there, it sound like the same problem.

I was not aware of this one. Worked fine on trusty :-(

tools.persondata@tools-sgebastion-07:~$ webservice --backend=kubernetes start
Looks like you already have another webservice running, with a gridengine backend
You should stop that webservice by issuing:

webservice --backend=gridengine stop

And then start it again with backend kubernetes by issuing:

webservice --backend=kubernetes start

Hmm … seems to be my error.

Sorry, my mistake.

Well, I started all my jobs (for historical reasons) from crontab with -once. I have rewritten some job which does its work, sleeps some minutes and then runs again. So I do not have to start it over and over again.

I accessed it from tools-bastion-02 with some script. Could be reproduces with command line

After a few minutes the problem vanished.

Maybe a second account in the database would be a simpler solution to double the number of connections? (just my few cents)

I'm the happiest guy in the world!

A dump would be fine. I do not need all, some a really large!

It is already set.

Would be fine when the data of s51412__data could be saved/restored onto the new server too.

Generally a user limit is okay.

I think there is no need to run such a query by cron or similar.

Yes! I have even started some virtual machine which I did not use for month and there the errors show up too, I tried en.wikipedia.org and fr.wikipedia.org (for sure I never visitied fr.wikipedia.org, since I do not understand that language).

On my local machine here at home I have installed a version from december 2017, when I grep in the source-hell I find …

Just an example: https://de.wikipedia.org/wiki/Internet_Movie_Database or en-wp: https://en.wikipedia.org/wiki/Robert_W._Chambers

A different example: ref-tags are enclosed in nowiki-tags
https://de.wikipedia.org/w/index.php?title=Maschinenkanone&diff=prev&oldid=174409703

@MusikAnimal … If you redirect to https://tools.wmflabs.org/wikihistory?wiki=enwiki I will try to enhance that tool.

enwiki works the same way as dewiki does. There is just an additional parameter "wiki=", example: https://tools.wmflabs.org/wikihistory/wh.php?wiki=enwiki&page_title=Crooked+House Okay, I did not change the frontend https://tools.wmflabs.org/wikihistory/ this is still the same as before and works for the german WP only.

I actually changed it a little bit. I have 10 queues. When I started to maintain this tool, somewhen in September/October it had 4 queues, but at that time it served only de-wiki (and two very small ones: ndl and als). Now I serve en-wiki too. 9 queues are for different sizes of the page. The change I did already is polling fewer times. The processes for the large files poll now every 15 seconds since the computation takes a long time, so it does not matter if the user has to wait 5 minutes or 5 minutes and 15 seconds. The queue for the small pages now polls every 2 seconds (instead of 1 second). 1 second was not invented by me, that was the value when I started to maintain the tool.

I can reduce the number ob jobs to ~4 if that is enough.

In the webserver-logfile of the tool wikihistory I see 2208 entries similar to the following

2017-11-07 11:42:14: (mod_fastcgi.c.2673) FastCGI-stderr: PHP Warning:  mysql_connect(): Too many connections in /mnt/nfs/labstore-secondary-tools-project/wikihistory/db.inc.php on line 7
2017-11-07 14:32:16: (mod_fastcgi.c.2673) FastCGI-stderr: PHP Warning:  mysql_connect(): Too many connections in /mnt/nfs/labstore-secondary-tools-project/wikihistory/db.inc.php on line 7

Same here: