Solid State (Oct 27 2009)

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

To post messages, you must log in.

AuthorMessage
Profile Matt Lebofsky
Volunteer moderator
Project administrator
Project developer
Project scientist
Avatar

Send message
Joined: 1 Mar 99
Posts: 1444
Credit: 957,058
RAC: 0
United States
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 · Report as offensive
Profile perryjay
Volunteer tester
Avatar

Send message
Joined: 20 Aug 02
Posts: 3377
Credit: 20,676,751
RAC: 0
United States
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 · Report as offensive
MarkJ Crowdfunding Project Donor*Special Project $75 donorSpecial Project $250 donor
Volunteer tester
Avatar

Send message
Joined: 17 Feb 08
Posts: 1139
Credit: 80,854,192
RAC: 5
Australia
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 · Report as offensive
DJStarfox

Send message
Joined: 23 May 01
Posts: 1066
Credit: 1,226,053
RAC: 2
United States
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 · Report as offensive

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


 
©2024 University of California
 
SETI@home and Astropulse are funded by grants from the National Science Foundation, NASA, and donations from SETI@home volunteers. AstroPulse is funded in part by the NSF through grant AST-0307956.