mersenne.ca server migration and probable downtime (Nov 2020)

[James Heinrich]

Originally Posted by axn

The site now renders.

That's more than I'm getting. Other domains on the server appear to be working, but for mersenne.ca I'm currently getting an Apache test page that I shouldn't be seeing. I'll look at it later, preferably after some sleep.

If the site is working for you now then great, if not then I'll try to fix it better in the morning.

[Uncwilly]

I tried out a few things and came up with this error. This factor came in after you started the transition.

[James Heinrich]

I forgot that PARI wasn't installed, it is now.
Also ran into another security setting where tasks couldn't see the server outside webroot, so none of the scheduled tasks worked.
I'm still putting out fires as I find them...

[James Heinrich]

One thing that puzzles me is that mersenne.ca shows up as expected under Firefox, but under Chrome I'm (still) getting a false Apache test page. Computers confuse me.

[chalsall]

Originally Posted by James Heinrich

One thing that puzzles me is that mersenne.ca shows up as expected under Firefox, but under Chrome I'm (still) getting a false Apache test page. Computers confuse me.

Working fine here; under both Firefox and Chrome. http and non-www URL redirects are working fine.

Could it be your Chrome cache? Have you tried turning it off and on again?

[James Heinrich]

Currently fighting with getting GMP support enabled on the web version of PHP. It's not a module that ships with the bundled version of PHP, and while it is enabled on the system installation of PHP, it's not enabled on the website PHP instance...

[James Heinrich]

Originally Posted by chalsall

Working fine here; under both Firefox and Chrome. http and non-www URL redirects are working fine.
Could it be your Chrome cache? Have you tried turning it off and on again?

It works fine everywhere I've tried, except Chrome on my main computer. Chrome on my other computer works fine, other browsers on this computer work fine. I've clicked the magic button at chrome://net-internals/#dns to no avail. Closed and restarted Chrome. Can't restart computer, in the middle of a week-long compression task I can't interrupt.

[S485122]

Closing Chrome doesn't. There always remain a few instances running. There might be a setting not to leave Chrome add-ons or whatever running when Chrome is closed. Otherwise, use ps and kill in Linux or task manager if in Windows to forcefully kill all instances.

Those programs caching, cached data from another cache are annoying (and probably present a security or privacy issue.

Jacob

[James Heinrich]

Originally Posted by James Heinrich

Pretty graphs, if anyone cares. Database import is highly CPU-limited (single-core), and you can see how the different data table structure affects IOPS: earlier it was doing very small rows (12 bytes/record I think) with a single key, right now when it's importing larger rows with multiple indexes. ETA says 3.9h

For completeness I'm posting the same graph showing the full almost-12h database import. Two bits of interesting: the middle 3h or so where the IOPS drops to almost nothing is during the import of the 1000 "known_factors" tables, I'm not entirely sure why the IOPS is so different compared to the other tables. They are smaller SQL files, in the order of 20-30MB each, so maybe (totally speculating here) the whole SQL file can be read into memory where as the larger (1-3GB) SQL files get read line-by-line (or at least statement-by-statement). Just a guess.

The interesting/scary part is starting at 1900h on the graph (0:00 UTC) where the scheduled backup I didn't know was scheduled started doing its thing, running out of disk space very quickly. It got to 98% full before I found and killed it. And then deleted the 80GB or so of backups it had already made, hence the steep plunge in disk usage afterwards.

I think mersenne.ca should be up and running for the most part now. I'll need to check for missing data points in the assorted tables from jobs that probably didn't run at their appointed times last night. I did notice that when I manually ran the sync-to-primenet job that it runs at least 10x (maybe even 20x) faster on the new SSD+Xeon server than it did on the old server. As

Let me know if you find anything egregiously broken. And if it's only mildly broken, check tomorrow and if it's still broken then, tell me about it then.

[chalsall]

Originally Posted by James Heinrich

For completeness I'm posting the same graph showing the full almost-12h database import.

Very interesting. Thanks for sharing.

If I may ask, what did you move to? An Ionos VPS, or something different.

I'm always interested in what VPS offerings there are out there...

[Mark Rose]

Originally Posted by James Heinrich

For completeness I'm posting the same graph showing the full almost-12h database import. Two bits of interesting: the middle 3h or so where the IOPS drops to almost nothing is during the import of the 1000 "known_factors" tables, I'm not entirely sure why the IOPS is so different compared to the other tables. They are smaller SQL files, in the order of 20-30MB each, so maybe (totally speculating here) the whole SQL file can be read into memory where as the larger (1-3GB) SQL files get read line-by-line (or at least statement-by-statement). Just a guess.

What version of MySQL are you running?

You shouldn't see IO stalls like that.

Do those tables have foreign keys that aren't indexed on the foreign table? Or any triggers that have unindexed queries?