Solid State (Oct 27 2009)

Message boards : Technical News : Solid State (Oct 27 2009)

Author	Message
Matt Lebofsky Volunteer moderator Project administrator Project developer Project scientist Send message Joined: 1 Mar 99 Posts: 1376 Credit: 74,079 RAC: 0	Message 943207 - Posted: 27 Oct 2009, 21:59:49 UTC
	As many of you already know, Tuesday is the regular outage day where we dry clean the mysql database and pack it down tight. We're recovering from it now. Today I also did some testing of the newly employed solid state RAID 1 on mork (the master mysql server). It seemed fine, so this device now holds the mysql/innodb logical logs, thus resulting in far less competing writes with the data RAID 10 (where the logs used to be kept). Will this help much? I dunno. A non-zero amount at least. I'm still assembling the new data pipeline. Got a few files in the queue now for multibeam analysis, but I can't seem to get a new astropulse splitter to compile. I need to recompile so that it reads the software radar blanking bit instead of the hardware one, but I'm hitting some library/include issues. Sigh. One of those problem you know you'll get working eventually but right now the path isn't exactly clear, and everything will be annoying until you finally get a successful "make." - Matt ____________ -- BOINC/SETI@home network/web/science/development person -- "Any idiot can have a good idea. What is hard is to do it." - Jeanne-Claude
	ID: 943207 ·

perryjay Send message Joined: 20 Aug 02 Posts: 3359 Credit: 9,967,372 RAC: 12,915	Message 943211 - Posted: 27 Oct 2009, 22:11:07 UTC - in response to Message 943207.
	Hang in there Matt, you'll get it going. I mentioned in your last thread I've finished three of the "new" WUs with your software blanking. They worked just fine and two of them had already validated. I think I've finished a couple more but the replica hasn't caught up yet so I don't know how they did. I'm sure they are fine too. Looking forward to the newly blanked APs, bet they are just as problem free as the MBs. ____________ PROUD MEMBER OF Team Starfire World BOINC
	ID: 943211 ·

MarkJ Volunteer tester Send message Joined: 17 Feb 08 Posts: 916 Credit: 14,865,332 RAC: 11,271	Message 943305 - Posted: 28 Oct 2009, 9:28:12 UTC - in response to Message 943207. Last modified: 28 Oct 2009, 9:28:48 UTC
	As many of you already know, Tuesday is the regular outage day where we dry clean the mysql database and pack it down tight. We're recovering from it now. Today I also did some testing of the newly employed solid state RAID 1 on mork (the master mysql server). It seemed fine, so this device now holds the mysql/innodb logical logs, thus resulting in far less competing writes with the data RAID 10 (where the logs used to be kept). Will this help much? I dunno. A non-zero amount at least. Good to hear. Will be interesting to see how they work out. Would also be interested to see how they go size-wise as they aren't that big. I'm still assembling the new data pipeline. Got a few files in the queue now for multibeam analysis, but I can't seem to get a new astropulse splitter to compile. I need to recompile so that it reads the software radar blanking bit instead of the hardware one, but I'm hitting some library/include issues. Sigh. One of those problem you know you'll get working eventually but right now the path isn't exactly clear, and everything will be annoying until you finally get a successful "make." Sound like my normal work day, trying to work out why programs don't work any more and fix without breaking something else. I'm sure you'll crack it soon, if you haven't already. Cheers ____________ BOINC blog
	ID: 943305 ·

DJStarfox Send message Joined: 23 May 01 Posts: 1040 Credit: 486,408 RAC: 78	Message 943336 - Posted: 28 Oct 2009, 14:06:40 UTC - in response to Message 943207.
	Matt, In the past, I had a specific server scenario where the log files were larger than the actual database. There was a lot of data moving around, and the transaction logs were a bottleneck, competing with disk I/O for data. I agree that the separate logical drive for transaction logs should improve overall write performance. Plus, it's always cool to have cutting-edge technology (solid state drives) a server. :) One other (real quick) thing to check is swapfile usage on your database server. You don't want the database engine using any swap. If you can find and remove any unnecessary swapping, then I/O performance will be a little better. Cheers to the new software-blanked radio data. That's a significant accomplishment for SETI when you stop and think about it. Can't wait to crunch some of it.
	ID: 943336 ·

Message boards : Technical News : Solid State (Oct 27 2009)