Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I plan on making a (servlet) application that stores its data in a MySQL server, but only reads them at startup time and write them every 4h.
I wish to let this application have as much RAM & CPU power as possible (hard drive access doesn't matter). Would open, write the data in the DB, then close the MySQL server every 4h be a good idea to reduce its RAM usage?

share|improve this question

2 Answers 2

up vote 1 down vote accepted

You can configure mysql to use a low amount of ram- however you obviously take a performance hit by doing this- however if your not dealing with much data, this might be worth it. It does sound like using a database here might be overkill (from what you have described)

share|improve this answer
    
You're right, not using a database is a better solution. Thanks :) –  POSIX_ME_HARDER Feb 13 '11 at 17:25

Hard drive access is the slowest option you have. Better to use ram when available.

MySQL will manage its cache appropriately. It you are concerned with limiting the RAM used by MySQL tune its memory parameters. If you give it too little memory performance will suffer.

You don't state your O/S platform but Linux and other Unix anything read from disk gets stored in memory buffers. These buffers are kept until memory is needed for another purpose. Depending on memory available you may gain no benefit from closing the database and reopening it.

share|improve this answer
    
I indeed didn't specify my needs for the writing/reading speed. I don't need it to be fast, just to be done using the less CPU & RAM as possible, thus the no-database solution being the best. Anyway, your answer is correct, so +1. –  POSIX_ME_HARDER Feb 13 '11 at 17:30

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.