I've released some of those auto holds as I see those BBS's are still online, so there is a back log of mail going out to those Systems. (I'm guessing they are on auto-pilot cause I havent heard anyway say they arent getting mail.)
I also gave the DB server some more memory - it looks like the linux kernel was killing it due to memory starvation.
I have noticed here in the last month or two that the net 3 hub gets put on hold because it doesn't answer, or because there is some failure.
I clear those holds periodically and things flow as expected until the next hold comes along.
I just cleared the holds on net 3 a hour ago or so.
Sometimes when I watch mailer sessions with hub 3 the session is very slow. This could also be the cause of failures. I don't know why the session progresses slowly. A lack of memory perhaps?
I just cleared the holds on net 3 a hour ago or so.
OK, there are probably a couple of reasons for this:
* There is major construction going on nearby, and they are constantly taking
my internet down for "maintenance" - and its prolonged (usually around 10hrs). >(They are rebuilding the rail line near me, and its an 18-24 mth project while
they move it above ground.). So I imagine this long outage is probably a primary reason.
(I have a hotspot, which gets traffic when my main cable goes down, so mail still flows, but only outbound from me.)
* I've taken hub down for updates.
* I nightly backup "pauses" the container and backs up the hub, but that shoul >only be a few mins. But that might be happing while there is a session active.
* My IPv4 link goes down (IP6 is much more reliable...)
Tonight I stopped the hub from accepting inbound calls while I cleared the backlog - it made it easier for me to trace a problem in the logs - which is when I noticed the kernel killing the db... ;)
How many failed attempts (and time) before your system puts me on hold?
Sometimes when I watch mailer sessions with hub 3 the session is very slow. >> This could also be the cause of failures. I don't know why the session
progresses slowly. A lack of memory perhaps?
Slow as in there is a delay before there are transfers? binkp by default has a
5 min timeout, hopefully not that slow that it times out?
Outbound mail bundles are built on the fly, and the DB has a lot of mail in it >(I've never deleted anything...), but it should be seconds before mail packets
are ready, not minutes...
That said, I've noticed the website is slowing down, so I may need to think about better DB indexes and/or deleting some mail.
To be honest, I'm surprised that memory is the issue - docker stats show it using < 200MB of the 512MB that I had assigned to the DB, yet the kernel was
killing it (oom-killer). I've doubled it just in case, but I'll need to keep a
eye on it.
To be honest, I'm surprised that memory is the issue - docker stats show it using < 200MB of the 512MB that I had assigned to the DB, yet the kernel was killing it (oom-killer). I've doubled it just in case, but
I'll need to keep an eye on it.
The mailer doesn't actually switch mail to hold but it it stops polling after 3 failed attempts. That will happen after about 5 minutes if any of the above is going on. I delete that failed call counter in nightly maintanance and during the day I do it myself if needed.
Slow as in there is a delay before there are transfers? binkp by default
I can watch outbound mail sessions if I switch to that window. Watching connects with hub 3 looks like the session is running 300 baud. Even so I have never seen a session failure, it is just slow.
Anyway, I think your new mailer/tosser is doing a good job although there may be more needed that you'll need to identify and sort out.
I think some of the default settings for memory/virtual memory in Linux leaves a lot to be desired, having vm.overcommit_memory = 0 (heuristic mode which tends to fail when an application wants lots of memory fast), vm.overcommit_ratio = 50 (only allow applications to use 50% of physical RAM) and vm.swappiness = 60 (rather high tendency to use swap).
Hope this helps!
So I had a look through the logs for the last couple of days. (I should expose this on the web UI as well...)
Most sessions with 4/106 are < 7s, with the occassional one at 18s. In terms of transfers most transfers are 2-4k.
In comparison, Spectres (which is EMSI/Zmodem) are 13-14s and are around 10-20k.
If you see a slow response on sending packets (to the hub), it may also be because your packet is being processed on the fly before the hub is ready to receive the next packet.
Anyway, I think your new mailer/tosser is doing a good job although there
may be more needed that you'll need to identify and sort out.
So at the moment, I dont think I have any issues to sort out. Everything seems to be working as I expect, although I do plan to work on some optimising the indexes in the DB so that the response to queries is a
little snappier, especially for the web ui.
| Sysop: | digital man |
|---|---|
| Location: | Riverside County, California |
| Users: | 1,044 |
| Nodes: | 16 (1 / 15) |
| Uptime: | 45:30:29 |
| Calls: | 500,942 |
| Calls today: | 5 |
| Files: | 109,374 |
| D/L today: |
5,229 files (1,003M bytes) |
| Messages: | 304,050 |