Just a heads up I was finding the index read slow to load today 10 secs plus etc... I did a restart of the PC and also ran message linking... it seems fine now but I will keep an eye on things I am running
Was it happening all of the time or just once? Sometimes hard drives
just get choked up with a lot of read/writes at the same time, or have
to dump buffers, etc. Or even hardware going bad.
Just a heads up I was finding the index read slow to load today 10 se plus etc... I did a restart of the PC and also ran message linking... seems fine now but I will keep an eye on things I am running
Was it happening all of the time or just once? Sometimes hard drives
just get choked up with a lot of read/writes at the same time, or have
to dump buffers, etc. Or even hardware going bad.
Linking shouldn't have made any difference in the speed that the index reader starts up so I am thinking that part was just coincidence.
On my Windows system it loads 200,000 messages in a fraction of a
second. It appears just as fast with 200,000 messages as it does with
0. Its running on a SSD though.
--- Mystic BBS v1.12 A43 2019/02/17 (Linux/64)
* Origin: Sector 7 (21:1/108)
I'm having the same issue, index reading is slow, takes about 5-10
seconds to come up with the list. I run my system inside a VM with Win
10 32bit.. Not sure if that is part of it. I am going to check defrag on the system.. Probably not the issue.. If you need anything from me let
me know..
ok something is up there.. i dont have a m! command.. what did i miss
on the upgrades?
M! is a menu command so if you haven't created one yet, you'd have to create an option on a menu somewhere that runs the M! menu command.
Just upgraded, still the same.. If you want me to send you any logs or anything let me know...
--- Mystic BBS v1.12 A43 2019/02/20 (Windows/32)
* Origin: The Wrong Number Family Of BBS' - Wrong Number ][ (21:4/131)
OK so you're ahead of me now on build but we're both running the same OS version. Are you running Win 7 32bit per chance? I am, so just curious.
You could shutter MIS and run a manual relinking process of your bases. This is what I did and asides a reboot of my PC it seemed to do the
trick. I did note than when I had the issue it happened via both local
and external login sessions.
Nope no difference, I re-linked my message base and no difference. STill asks if I want to remove what is in %1 (display code) then asks
subscibed etc which I assume is correct the the %1 I don't think so (I
am using Rumors now).. Gonna try another reboot and check again...
after taking a backup I would run a purge and pack...
..is this when you login locally?
Thanks for the help.. All setup but it is still slow, I have rebooted
the VM, and when I go into the Index Reader, the first thing that pops
up is if I want to unsubscribe from a message base. Then it asks as I am
The things you're describing isn't how the reader works. It doesn't ask you anything when you start the reader. You have something very broken, but I honestly can't really understand what you're saying about %1 and
so on. None of that is making any sense to me.
Updating or linking is not going to effect anything as I've mentioned in the past. The only thing that could improve it is packing the message bases to repair corrupted bases, but I really don't think the problem is with Mystic based on what you're describing.
That's what is weird to me, when I go into the new Indexer, it asks if I want to remove (%1 is the rumor at the main prompt, so I have one that says this space for rent it comes up and says remove This space for
rent, when I hit NO, it shows a menu that says subscribed, unsuscribed
and another option I choose subscribed and it lists the message bases..
I am going to try packing the message base now.. I will post tomorrow, I am pretty sure I have the message bases get packed every night.. If I don't get anywhere with it tonight I will zip up my message base and
send it off to you...
As for hardware, I am running a I3 16Gig Ram, Win 1064 bit, 3.5ghz, the BBS is in a Win 10 32bit Virtual Box, 4 gigs ram, 2 cores, never had any issues before, could be a bad Virtual Box for all I know...
I'll let you know how it goes with packing the message bases...
Ok... I ran a purge and pack, no difference.. My message bases are on a Server based drive, not on the main drive here if that matters.. I have even defragged the Message base drive.. I am at a loss, one thing now though that is urking at me, this seems to have started either right
when OR right after I moved to Win 10.. I still have my old Win 7 system
I am going to test it to see if it was doing it, I am also going to upgrade that one to A43 and see what happens... I will play with that tomorrow night... Oh yes it is both Local and via external logging on...
the past. The only thing that could improve it is packing the message bases to repair corrupted bases, but I really don't think the problem is with Mystic based on what you're describing.
You can send me your msgs directory if you want me to run it here and
look at it, but I suspect its a non-Mystic issue. What hardware are you using, what drive, etc?
Did you follow the instructions when upgrading? You need to copy msg_index.* into your TEXT directory from the latest A43 release (and userchat.*). See if doing that will help resolve the wacky behavior but it shouldn't affect speed.
Okay then its probably not the issue since you pack regularly. BTW packing every night is pretty overkill, packing is meant to be more of a weekly or monthly thing you do when the entire BBS is offline.
That's what is weird to me, when I go into the new Indexer, it asks i want to remove (%1 is the rumor at the main prompt, so I have one tha says this space for rent it comes up and says remove This space for
Did you follow the instructions when upgrading? You need to copy msg_index.* into your TEXT directory from the latest A43 release (and userchat.*). See if doing that will help resolve the wacky behavior but
Did you follow the instructions when upgrading? You need to copy msg_index.* into your TEXT directory from the latest A43 release (and userchat.*). See if doing that will help resolve the wacky behavior but it shouldn't affect speed.
Okay then its probably not the issue since you pack regularly. BTW packing every night is pretty overkill, packing is meant to be more of a weekly or monthly thing you do when the entire BBS is offline.
Yeah thats what I am wondering if there is something weird with it being
a VM. Your computer seems faster than the laptop from 2011 that my BBS runs on and its so fast I can't even tell the difference in speed
between going from the main to message menu and from the message menu to opening up the index reader.
I can't see why it would be an issue re server based drive. Defragging drive etc I don't think is it either. So you're on Win 10. OK. Mmm...
it's not that there's some other process running on the box taking up
CPU resource or something like that perhaps?
Okay then its probably not the issue since you pack regularly. BTW packing every night is pretty overkill, packing is meant to be more o weekly or monthly thing you do when the entire BBS is offline.
Heh I purge and pack nightly, should it be purge nightly and pack weekly?
I was experiencing a similar issue with the new index reader where it
kept asking if i wanted to unsubscribe from areas etc. I extracted the msg_index.* files files from the installer and copied them to the TEXT directory and everything is working normall now.
Offline?? I pack as part of my daily routine, which I am now going to change to a monthly thing. Should I be doing this when the BBS is
offline? If it doesn't matter I will change it over to a Monthly thing...
I tested my Win 7 setup and it's the same, so it's weird.. I'm gonna play with the settings of the VM to see if adding more RAM or anything else might help.. Now that the wackiness is gone I can move forward to other things..
It shouldn't hurt to run it nightly if you want to, its just that if anything else is accessing the message bases there is always a chance
for corruption to occur.
Well its the safest way to do it. If other things are accessing the message bases at the same time, there could be a race condition that causes corruption.
Its pretty rare but it has happened to people. One possible solution
that will work on all platforms is if I create a "BUSY" system for
message base access like I have for echomail transfers. This is
something for me to think about in the future.
If you want to (assuming the data isn't too big) you can ZIP up you msgs folder and I can try to run it against your exact message bases to see
if it slows down for me.
gotcha, and the BBS event type is to try and negate this right? I used
it for a while but it didn't really seem to do much asides ensure folks were logged out at a set time. Which is good. But how to ensure they
don't login in again and do stuff while such MUTIL functions are running?
If you want to (assuming the data isn't too big) you can ZIP up you m folder and I can try to run it against your exact message bases to se if it slows down for me.
Shouldn't be too large.. Let me know where to send the zip file and I
will do so... :)
Just another update on this:
I tested it on my Pi today and it was still instant. I made a message base with 50,000 messages in and then made 4 copies of it, and even on
the Pi 3 with a generic SD card it loaded 200,000 messages pretty much instantly (less than half a second)
Have you tried it outside of whatever you're using to run the virtual machine?
Right it just logs them out. The reason it doesn't do more is that these days the refusal needs to be implemented at the server level, since
things like NNTP, SMTP, POP3, etc can all access the message base. So
the system to enforce a window has to be rebuilt. I really should get that done.
I am going to test that tomorrow, gonna install on another computer and see what it does...
Right it just logs them out. The reason it doesn't do more is that t days the refusal needs to be implemented at the server level, since things like NNTP, SMTP, POP3, etc can all access the message base. S the system to enforce a window has to be rebuilt. I really should ge that done.
Thanks that makes sense and ties to what I was thinking...
The issue I have is that there is no user interaction with those
servers. With a BBS login you can warn them that they're being disconnected. I've never been satisfied with the idea of just ending a connection out of nowhere for the other servers.
Hey bud.. Thank you for all the help.. It's the VM that is causing the slowness... I just moved the BBS to a 3.7 i5 it took all of 2 seconds to come up.. Guess, I need to make a decision on whether to keep the BBS in
Heh I purge and pack nightly, should it be purge nightly and pack weekly?
Heh I purge and pack nightly, should it be purge nightly and pack wee
You know, if someone just jumped into the middle of this conversation
that might sound rather ... umm ... personal.
| Sysop: | sneaky |
|---|---|
| Location: | Ashburton,NZ |
| Users: | 31 |
| Nodes: | 8 (0 / 8) |
| Uptime: | 203:09:56 |
| Calls: | 2,083 |
| Calls today: | 1 |
| Files: | 11,139 |
| Messages: | 947,992 |