Single SSD PC build

Toggle sidebar Toggle sidebar
B

Bro_beard

Reputable
Jun 25, 2015
14
0
4,510
Hey guys and gals,

I'm building a PC for work that needs to be able to process files (databases + large image sizes) that end up being anywhere from 500mb - 2gb or more. I'll be merging/exporting/accessing these files on a day to day basis (in a 3rd party program) and am looking for the right set up to make this a bit more efficient.

I was tracking some data via Resource Monitor and it seems like the HDD (1TB 7200RPM) is taking a substantial load during processing these files and the RAM usually looks pegged as well (6gb). The i5 processor is at about half of the full load.

I'm thinking a 1TB SSD as the only HD because of the amount of data I'll need saved locally and accessible. 16gb of RAM and another i5 (4690K this time).
 
Solution
kanewolf
If 6GB RAM works OK, then with 16GB, you could create a 4GB ramdisk to use as the working buffer. Ramdisk will be even faster than an SSD. You might find that you will improve your I/O enough that you could become CPU bound.
Sort by date Sort by votes
kanewolf

kanewolf

Titan
Moderator
May 29, 2013
37,278
3,264
156,790
If 6GB RAM works OK, then with 16GB, you could create a 4GB ramdisk to use as the working buffer. Ramdisk will be even faster than an SSD. You might find that you will improve your I/O enough that you could become CPU bound.
 
Upvote 0 Downvote
Solution
B

Bro_beard

Reputable
Jun 25, 2015
14
0
4,510


I think the only issue with that is the information I'll be processing is VERY important and I can't afford to lose any of it, like ever. There will be back ups but this machine will hold the responsibility of storing all the smaller files in one monstrous file. The larger file is the reason for a large SSD. Will using a RAMdisk buffer increase the read/write to the HD/SSD?

The size of the amount of data that I'll be storing yearly (cannot be removed or backed up sooner so these files NEED to stay on the C: because of the way the 3rd party program works) usually ends up being > 500gb.
 
Upvote 0 Downvote
kanewolf

kanewolf

Titan
Moderator
May 29, 2013
37,278
3,264
156,790
The ramdisk would make a perfect buffer to hold each new (<2GB) file to be merged. Depending on the program doing the merge, it may benefit from having a ramdisk for temporary files. Without knowing more about your application, I can't speak more specifically. I have gotten very good performance improvements from a ramdisk. It is always something that has to be benchmarked. You would also want a UPS to allow you to gracefully shutdown in the event of a power failure.
 
Upvote 0 Downvote
B

Bro_beard

Reputable
Jun 25, 2015
14
0
4,510


Thanks for all your help. I think this will work perfectly after doing some more research so I fully understand what the RAMdisk does. I think I'll stick with the 1tb SSD idea since the size of the file after all the merges will be pretty big but adding in that RAMdisk for the merge files sounds like a good idea.

Last question, the smaller file that I will be merging would have to be loaded in to the RAMdisk first right? Then merged to the main file on the SSD? Basically, I'll be pulling files from a network location straight to the RAMdisk everyday and then writing to the main file on the SSD.

BTW: The program is called Flow from Photolynx. It combines databases with images to merge with other databases and images.
 
Upvote 0 Downvote
jsmithepa

jsmithepa

Polypheme
Jun 14, 2014
13,096
263
60,840
A Ram Disk can be used 2 ways: (1) As a cache for SSD/HD, or (2) As a super-fast scratch pad.

(1) Would only help if the size of the dataset you are working with constantly FITS WITHIN it.

(2) You have to know the size of the scratch pad.

The best thing to do is to shoot an email to the App developer, they know exactly how their App works and should be able to give you pointers what to do to optimize their App.
 
Upvote 0 Downvote
You must log in or register to reply here.

TRENDING THREADS

Latest posts

Moderators online

Share this page

COMPANY
RESOURCES
FOLLOW
Top Bottom