Is anyone seeing the latest version crash more often. My V3.3 seems a lot more unstable and rarely stays running for more than 24hours.
would be interested to see if anyone is having the same problem.
thanks Mark..
V3.30 stability
Re: V3.30 stability
I have seen more crashes than before and a database corrupt error which I hadn't seen before. In addition I have seen in a couple of ocassions the CPU going up to 50% and staying there. Housebot continues running normally but I have to restart it to get my CPU usage down. Not sure if it is related to 3.30 since I am constantly changing the configuration but in my last crash when I hda problems with the database the only way I was able to solve it was going back to 3.20. I am now back to 3.30 again, lets see.
Saludos,
Victor
Saludos,
Victor
-
Richard Naninck
- HouseBot Guru Extraordinaire
- Posts: 1121
- Joined: Tue Sep 28, 2004 7:49 am
- Location: The Netherlands
Re: V3.30 stability
There has been a lot of email traffic outside the forum to get to the bottom of at least one error that seems related to hanging tasks. The one thing that resolves this for now is setting the cpu affinity to use just one core. Obviously this is only true if your system is running dual core or higher. You might try to use only one cpu core and check again the uptimes. For some reason a hanging task gets a runtime error in the task thread, but HB doesn't shutdown and doesn't produce a dump.
Re: V3.30 stability
only running a single core. so that is not it my end.
any more ideas?
any more ideas?
-
Richard Naninck
- HouseBot Guru Extraordinaire
- Posts: 1121
- Joined: Tue Sep 28, 2004 7:49 am
- Location: The Netherlands
Re: V3.30 stability
Meaning you don't have a dual core cpu? In that case my reply doesn't help you.sundodger wrote:only running a single core. so that is not it my end.
any more ideas?
If all is OK, whenever HB crashes it produces a dump. If these dumps are consistently the same, you should report those to Scott. Even if the dumps are different all the time, they might have something in common. The HB Server should be able to run without any issues. I have seen uptimes of above 30 days so if anything is wrong and it is HB induced, you should/could report it...
Re: V3.30 stability
Mark,sundodger wrote:Is anyone seeing the latest version crash more often. My V3.3 seems a lot more unstable and rarely stays running for more than 24hours.
would be interested to see if anyone is having the same problem.
thanks Mark..
When the system crashes, it should create a file in the \HouseBot\Dump directory. Please send me (support @ cebotics.com) the latest dump(s).
Scott
Re: V3.30 stability
If anyone having an issue where their database gets corrupted due to the system crashing, be sure to check and make sure that the write caching for the disk (a windows setting) is disabled.vcruz777 wrote:I have seen more crashes than before and a database corrupt error which I hadn't seen before. ...
Scott
-
Richard Naninck
- HouseBot Guru Extraordinaire
- Posts: 1121
- Joined: Tue Sep 28, 2004 7:49 am
- Location: The Netherlands
Re: V3.30 stability
Scott:
Is that write caching the same as having no virtual drive other than memory only? I don't get to see much dbase errors and I know how to fix them easy but occaisionally I get my dbase corrupted when something heavy happens and HB crashes or the PC reboots while HB was running (blue screens)
Is that write caching the same as having no virtual drive other than memory only? I don't get to see much dbase errors and I know how to fix them easy but occaisionally I get my dbase corrupted when something heavy happens and HB crashes or the PC reboots while HB was running (blue screens)
Re: V3.30 stability
When you say, 'except for memory', my response is that you want to try and remove any memory caching from the writes as much as you can. Now there are obviously memory transfers along the way, but the trick is to not cache anything in memory.
In Vista, you can configure a drive (it may depend on the capabilities of the drive,driver,or interface), to 'enable write caching' on the disk. You can find the option if you dig into the properties of the drive under a 'Hardware' tab in the Property page. In XP I think there was a policy option in same general area to optimize performance (via caching).
It's an option that will greatly increase write speeds, which is very handy for a file server that you write (not read) a lot of data to. The bad part about it is that when data is cached like this and the system goes down, there's really no telling what state the physical file (HouseBot database or any other file) was in when it was last written to, but you can probably be sure that it was not with the complete data (since some of the data would have still been in the memory cache).
On my development system, I constantly kill HouseBot in the middle of a debugging session where the database would be left open. I can't remember the last time I corrupted my own database, so I feel fairly confident in the jet/access DB and drivers at least under this particular setup. That's why I'm wondering if caching is somehow involved in these DB corruptions.
In Vista, you can configure a drive (it may depend on the capabilities of the drive,driver,or interface), to 'enable write caching' on the disk. You can find the option if you dig into the properties of the drive under a 'Hardware' tab in the Property page. In XP I think there was a policy option in same general area to optimize performance (via caching).
It's an option that will greatly increase write speeds, which is very handy for a file server that you write (not read) a lot of data to. The bad part about it is that when data is cached like this and the system goes down, there's really no telling what state the physical file (HouseBot database or any other file) was in when it was last written to, but you can probably be sure that it was not with the complete data (since some of the data would have still been in the memory cache).
On my development system, I constantly kill HouseBot in the middle of a debugging session where the database would be left open. I can't remember the last time I corrupted my own database, so I feel fairly confident in the jet/access DB and drivers at least under this particular setup. That's why I'm wondering if caching is somehow involved in these DB corruptions.
Scott
Re: V3.30 stability
Scott,
The suggestion to disable the disk on-board write cache is a good one, but folks probably should be aware of severe performance consequences. As I posted elsewhere:
"On my laptop, with WCE (write cache enabled) I get 20MB/s throughput for 64K OS-cache-bypass writes; without WCE I get only 3.6 MB/s."
Similarly, to hibernate (saving memory image to the disk) takes several minutes as opposed to about half a minute with cache enabled.
It may not matter if the computer is used solely for HouseBot.
The suggestion to disable the disk on-board write cache is a good one, but folks probably should be aware of severe performance consequences. As I posted elsewhere:
"On my laptop, with WCE (write cache enabled) I get 20MB/s throughput for 64K OS-cache-bypass writes; without WCE I get only 3.6 MB/s."
Similarly, to hibernate (saving memory image to the disk) takes several minutes as opposed to about half a minute with cache enabled.
It may not matter if the computer is used solely for HouseBot.
Re: V3.30 stability
Victor,
Yes, I tried to point out the performace issue in my post. I agree that it is a significant performance difference. My HouseBot server also doubles as a file server and even runs MCE. I enabled write caching to get all of the files (photos & music) transferred quickly, but then disabled it and I really don't see any performance issues, since generally music and photos are read from the disk and this option should only effect writes. I'm actually pleased that MCE seems to run without issue either.
Yes, I tried to point out the performace issue in my post. I agree that it is a significant performance difference. My HouseBot server also doubles as a file server and even runs MCE. I enabled write caching to get all of the files (photos & music) transferred quickly, but then disabled it and I really don't see any performance issues, since generally music and photos are read from the disk and this option should only effect writes. I'm actually pleased that MCE seems to run without issue either.
Scott