Are these statistics dependable? Almost 9 million queries per hour?!
I have been tracking this. I believe that the whole yacy.space near denial of service level queries are what is making that crazy number appear. When yacy.space is down, the numbers fall into normal levels, and when they are hitting all my nodes with 3-6 queries per second, the number is way up there. In my case: 78 nodes x avg 4.5 queries per second = 1,263,600 queries per hour JUST to my nodes. Iāve made a polite attempt at contact, and if things donāt change Iām going to contact Digital Ocean and see what can be done. Iām still holding out hope that they didnāt mean for things to go the way they have, but Iām going to need an explanation for being flooded with searches like: āBaxterās pasta menu prices for today 3/1/2020ā which no human anywhere is typing into a search engine in 2026.
I had my Yacy Mission control running through the event looking at my server.
At 10 seconds per sample, we can estimate it from the graph.
The right edge is around sample 182,208, and the big peak is around 123,000.
Difference:
182,208 ā 123,000 ā 59,208 samples
At 10 seconds each:
59,208 Ć 10 = 592,080 seconds
Thatās about 164.5 hours = 6.85 days.
So the big peak happened roughly 6 days 20 hours ago.
11 August 2026 ā YaCy Network Load Event
YaCy Mission Control recorded a period of unusually heavy system load beginning around 11 August. The peer experienced repeated sharp load spikes while memory remained under control and the document index continued operating normally. The event later subsided, suggesting a temporary burst of very high network/search activity rather than a permanent system failure.
11 August 2026 ā Extreme YaCy Network Load Event
A YaCy server recorded an exceptional burst of network activity, with log analysis showing approximately 115 actions in a single second. System load produced repeated large spikes while the peer continued operating and the index remained active. The intense activity later subsided, indicating a temporary high-volume network event rather than a sustained system failure.
Fascinating insight, thanks for sharing! Is that software available? If so, will it do multiple nodes?
Iām still working on it and testing. Multiple nodes well it should not be too hard but I have to try and code it.
You gave a thorough summary of the storm that passed through our network, like a meteorologist who documents a hurricane. 
Itās impressive that your machine stood strong through the storm without crashing.
I have shared the raw data.
I was monitoring and crawling with yacy8092 for the start of the records.
Then later on I switched to an Android Box. CPU = 4
http://58.96.112.6/index.php/s/pGGSfxgGxgifWnm
I donāt know that much office functions producing graphs etc.
Yes the fans were getting quite cranky during the event.
I had to increase the memory on 2 peers.
I took a look at the data. I think you already summarized it best, so I have nothing to add.
Did we go sixteen years back in time?
Sounds good. If you decide to release it at some point, especially as its own repo, I could contribute. 
It makes as much sense as any of the rest of this. The guy is still hitting still hitting my nodes with 3-6 queries per second. I decided to be nice, so whenever they get a query, they respond with the snippet title and description customized to deliver a very nice message explaining the damage done, and asking them to come into the forum and converse if they arenāt a bad actor doing this on purpose.
So far, nothingā¦ As far as I can tell they are datamining the yacy network, but for what specific purpose, I have no idea. I did notice that the searches seem to be different from node-to-node, even when they come in at the exact same second.
One thing has become very clear to me: This seems like some kind of a list of queries that are being fed into the network. Iām downloading and storing the local query logs to a central location and then will make it presentable to send off to digital ocean and see what they say. I suspect they have seen my message, because the day after I did that, yacy.space went down for 48 hours, and when it came back it was no longer hammering the web search interface, at least on my nodes.
When you take the logs, the fact that they are still hammering the API 3-6 times per second on each node, that is an average of about 21,000 queries per minute, just to the 78 nodes I currently have up. 1,263,000 per hour, 30,326,400 per day. Seems a little excessive, doesnāt it? 
And thanks to @roamn and their very nice graphical tracking it can all be visualized and better understood. (Thanks again for that. Seeing it, helped.)
I had to disable heuristic crawling on all my nodes, which is a shame since that is a nice way to expand the search results, as this personās āattackā was causing queues to fill entire drives on smaller, drive limited nodes. The current way that Yacy writes the local queue entries to the drive make it very problematic to store/delete several million queue entries.
Hopefully this will all be over soon, but it did point out a few places things can be improved, soā¦ silver linings.
We must protect ourself. Heavy-load participants shall not given an opportunity to harm the p2p network for the sake of transparence and openness. We should introduce some limitations.
What are your suggestions? I would consider to make request limits just like a nginx would limit with a āleaking bucketā system, see Rate Limiting with NGINX ā NGINX Community Blog
That should not prevent normal peer operation while protecting everyone.
Yes, currently for solr queries in YaCy, itās either ON or OFF, but there is no way (that I found) to limit them. The web interface has rate limiting already, but a direct solr query bypasses that setting.
Apache Solr has rate limiting available.
However, that limit would apply to everyone, even authenticated users. So, in a query flood, even the admin could get locked out.
Your idea to use NGINX (as a reverse proxy) could solve that problem, allowing authenticated users to continue making solr queries, even during rate limiting.
Very good! And it is impressive that you could modify the responses.
I would not be surprised if AI is being employed to create the queries. They are often unique, as you noticed. If not AI, then some other script is being used to put keywords together. But I doubt human fingers are actually typing in the queries which enter the network. Do you ever notice misspelled words?
You are still noticing a high volume of queries. I did not realize it was still going on, so thanks for sharing the report.
ah no, that was a misunderstanding. I did not suggest to use nginx, I suggested to use the same rate limitation principle that nginx uses.
Thanks for chiming in. I read The link you provided, and of the methods listed there, somd workable. The āleaky bucketā sounds promising, and I think it would work out well. With the current yacy.space problem, I think they will just set their QPM to whatever the bucket will allow, and keep right on doing what they are doing. Generally though, I think it is a great idea.