Factordb wipeout?

[BudgieJane]

Originally Posted by Happy5214

It's been 18 hours, and it still has the same message.

It now says "Full database check (will take some time)"

[MDaniello]

I briefly got access back to factordb, but then i got a "2002: SQLSTATE[HY000] [2002] Connection refused" error and now is back to "Full database check (will take some time)".

The database was 80.xx %, so Syd managed to recover part of it.

[RichD]

I had brief access also. When I inquired into AS 4788 it only returned the first few hundred indices. Each subsequent inquiry added a few more terms each time. I guess the internal workers were factoring the small numbers. I wanted to see what happen when it got to a C70 but it went offline too soon.

As I previously mentioned it looks like all the numbers are there but the links or association with its larger composite is missing. Which makes the data base useless in its current form. I am guessing the links make up the missing 4% which unconnected stated earlier. (Status page showed 80% when I had brief access.)

[MDaniello]

It seems the site is available again, while it keeps debugging the db in the background (it's actually showing the IDs it's working on in the status page).
The database is 817,667MB (81.77% used)

[DukeBG]

I tried uploading a primality cert. Looks like it started processing. Hopefully this won't bother any recovery processes if they are still happening

[chris2be8]

Originally Posted by RichD

I wanted to see what happen when it got to a C70 but it went offline too soon.

I've restarted my script to factor numbers between 70 and 78 digits, so they are being cleared out. But it runs on an old and rather slow PC so can take some time if there are a lot to do.

It wasn't factoring numbers above 54 digits before the outage but is now clearing them up to 70 digits. Which saves me from having to work in that area. And I still have to skip over a few errors (at 71 and 75 digits I think).

Also factordb's load average is about 20 now. Is someone hammering it?

Chris

[yoyo]

There are some scripts running which fetch the last entry of a e.g. Aliquot Sequence. The Aliquot Sequence tables are tmp tables which were truncated. Now they are recreated on first access by using the known factors. This leads to millions of DB requests.

[chris2be8]

Now nearly all the 79 digit composites have been factored (kudos to whoever did them) I've update my script to clear 70-79 digit numbers.

Chris

[EdH]

Originally Posted by chris2be8

Now nearly all the 79 digit composites have been factored (kudos to whoever did them) I've update my script to clear 70-79 digit numbers.

Chris

I did turn some cores loose yesterday (over 100), but not sure how responsible I was, since when I stopped them all last night, almost all were crashed for some reason.

I've also created a Colab instance that factors via GMP-ECM with the GPU branch. I ran that for a while against the 80 dd composites, but it's much slower than the YAFU version for most composites.

[chris2be8]

Can your cores cope with factordb handing them a prime number when they ask for a composite? My scripts have had to skip over 1111111111111111111111111111111111111111111111111111111111111111111111111111091 an annoying number of times.

Also there's at least one broken 79 digit entry in factordb. wget returns "500 Internal Server Error" when it tries to download it.

If you want to set them loose again aim at 80 digit numbers, there's plenty of them now.

Chris

[EdH]

When I really turn my machines loose on the composites for any length of time, I have an RPi, tracking the composites received, to cut down on duplication. The troublesome 79 digit gets run once and then all the machines ignore it. In reality, if I don't have the RPi running, my script processes the 79 digit number so fast it doesn't take too much time before it's on to the next, but it does show up often.

Something caused most of my machines to fail yesterday when they were running the composites. I didn't investigate, but every one of the failed machines was stuck in a failure loop trying to retrieve the next composite. A restart of the script succeeded without issue, but as to what was going on, I don't know. This is what was showing:

unrecognized token: td
Error, no result found
Factoring 9 digits: width=14%

All my machines are running a CADO-NFS job now, but I have a Colab session running the 80 digit composites, also. The Python3 script I'm playing with right now on Colab is using the GPU branch of GMP-ECM and only hitting everything lightly (11e2/11e3). It's having a success rate of a little over 50%. (The last run factored 21 of 30 in, I think, about five minutes.) Unfortunately, it also means only smaller factors (<20 digits, mostly) are found and the composites that survive will have to be run again. To counter that duplication, I hope to build a YAFU version, similar to the one I already have, that uses the GPU, but I'll have to modify the ECM calls within the YAFU code and limit the curves sent with higher B1s, or the ECM part will take a huge amount of time trying to process >3000 stage 2 residues across only two CPU cores for higher b1s.