I moved this to the "Troubleshooting" forum. Is this the correct place?

If this is happening on any Mac or Linux machines, you could run Zotero with real-time debug output enabled. If you let that go for a while and then zip it up and send it to support@zotero.org with a link to this thread, we can see what's going on. Unfortunately on Windows generating real-time debug output is too slow to be a viable option. You could try going through the Debug ID steps and keep the preferences window open, but I'm not sure if you'll be able to submit the output when the sync is going.

I don't see anything out of the ordinary in the server logs, at least for your account—I see some repeated download attempts, but they're not particularly large and they certainly shouldn't cause the kind of hang and memory usage increase you're experiencing.

(Something seems wrong here, but whatever the cause of this, we're overhauling the way syncing works in Zotero 4.0 to avoid this sort of trouble—Zotero will sync items in small batches instead of syncing everything that has changed at once.)

And it doesn't need to cover several hours, if you're able to submit it sooner—10 minutes of attempted syncing should be more than enough time.

I fired up a Linux laptop. Updated Zotero. Trying to get the realtime output.

How do you get debug output with standalone?

How do you stop auto-sync with standalone - if you can't get to the menus?

First few runs - segfaulted and got out of memory.
$ ./run-zotero.sh > zot_log
###!!! ABORT: OOM: file /builds/slave/rel-m-rel-xr_lx_bld-0000000000/build/xpcom/string/src/nsTSubstring.cpp, line 533
###!!! ABORT: OOM: file /builds/slave/rel-m-rel-xr_lx_bld-0000000000/build/xpcom/string/src/nsTSubstring.cpp, line 533
Segmentation fault

$ ./run-zotero.sh
out of memory
Segmentation fault

I did manage to get a debug log sent to zotero server from the advanced pane in preferences, ID in the previous message.
Is that the same output that real-time logging would provide?

And I just got this error
Report ID: 1109430203

Is there a reason you just added a new group with another 8700 items? I'm still looking into the problem with your other library, but, for what it's worth, that's not going to help your situation—as I said above, Zotero currently syncs everything that has changed at once, so that's just going to create much more data for Zotero clients to download. Right now you have a huge in-process download on the server that may not finish.

Background: For my setup I have 3 computers. 1 Linux, 2 Windows, lets call them L1, W1, W2. I do work on one of them, and make sure the syncs work to the 2 others. Mainly I work on L1 and W1, and test with W2. Over the last 2 weeks we've done a lot of work. And it all syncd, even to other users in the group until just a 2 days ago when this started.

On L1 I created the new group lib as a copy of the original, without any tags. I was guessing the volume of useless tags imported when into the library could be causing a slowdown. There are about 280000 tagitems(?correct field name) in the database. I created it by copying everything to the new group without any tags or child items. Hoping this would be a "cleaner" version. This version syncs just fine (on linux if that matters) for some reason. Again this is on L1 which is last place I successfully synced "TO" the Zotero server. I didn't actually want to sync it, but it automatically started on that client, I thought I had autosync turned off, I didn't.

Not sure where the 30 days and 3600 items (does that include tags?) is coming from. I was updating (using and syncing) W1 and W2 much more often than that, much more recently. The computer W2 is on isn't even 30 days old (this is the one I'm mainly reporting with, where I discovered the problem)

W2 ran just less than 7 hours trying to sync without finishing. So I killed it and dropped the entire library from W2 by doing a "Restore from Zotero Server". It has been running since 5pm last night, 17 hours, and it's still spinning. I've now killed that one.

W1 is still in the same state ( can try the sync again when you instruct me to ), but not trying to sync at the moment.

On L1 I've deleted all the items in the new group. (There was no option to delete the group, when it's done deleting items, I'll go to the website and try to delete it)
It is syncing now, so it should be empty soon.

I'll wait to hear from you before setting up any other syncs. However other users may be syncing.

So everything on your account from the last day is likely irrelevant, since that was due to a stalled download on the server from the new library. That group now appears to be empty, and your stalled process is gone.

The only download processes I see from your account have a last-sync date of January 25th. (3600 items includes notes and attachments.) I see plenty of uploads since then, meaning at least one of your computers is fully in sync and is uploading new data (which happens after downloading), but the behavior you describe would only happen if there was a large download, which would make sense with a last-sync date of a month ago. (Syncs that don't download anything aren't logged, so the computer that's just uploading wouldn't show up in the download logs if no other data has been added to the group.)

I didn't check before, but it looks like there are now no other users in that group. Is that correct?

Having lots of tag-item associations is likely part of the cause of the hang. If you want I can provide some code you can run to clear out all the tags (or all the automatic (orange) ones, if that's the problem) in that library. Your approach—to create a new library without tags—is also OK, but you'd want to delete the old one once that was uploaded so that your other clients didn't have double the amount to download.

OK, fair enough, and sorry for the trouble. The new syncing architecture, and some sort of ability to clear out lots of unwanted tags, should help avoid problems like this in the future.