MineOS attaches to minecraft-created logs, and server packs like these do a particularly excellent job at producing an enormous amount of loglines.
MineOS can’t (or won’t) determine which log lines to send, it sends them all. This can, depending on the server type, mean thousands of lines in a very short period of time.
The webui attempts to curb any crashing by seeing if 160 lines in 2 seconds gets flooded in (and it happens), and that kind of log traffic really bogs down the browser (think of it like: the size of your log literally just gets added to the amount of memory your browser needs).
The rate-limiting is only a half-measure; it helps reduce the browser’s likelihood of using up all your desktop’s memory and slowing it down to a crawl, to the point where it crashes. On the other hand, the log file continues to generate tons of logs and the backend continues to transmit it. This transmission has a little cost, though it’s dwarfed by the performance cost of actually displaying it.
Linked above, you can see a workaround that actually just removes a given logfile from the webui (but more accurately, it removes it from being tailed on the MineOS backend). This solution actually solves both ends of the problem, which is the tailing memory/performance cost and the transmission to the browser (mem/perf costs). It also makes it so that particular file isn’t browsable in the webui.
So it’s a tradeoff. If the value of the logs is marginal, remove it from tracking and you’ll have all the performance reclaimed. Otherwise, just wait for an amount of time when the servers no longer produce excessive logs, and then refresh (re-enabling tailing)