> Eventually something will give and you'll get a wait as something is spilled > to something, ie cache to physical drive. > Also different settings suit different work loads. I have a number of +128GB > units configured differently depending on what they need to do. The ETL > setting only gives Java 8GB but the OS will consume close to 90GB virtual for > the process as it basically dumps into file cache. At some point though that > cache is written out to noon volatile storage. As the units have 24 cores I > can actually run close to 12 processes before things start to effect each > other. If you consider server class hardware there's a lot of thought to > cache levels and how they cascade. > Switch the SATA for M.2 and you'll move the issue somewhere else...
Well yeah, but having a problem at 10K triples/seconds is not the same problem as 1M triples/seconds. I'll gladly "move the problem elsewhere" if I knew how to get to 1M triples/seconds. Moving from SATA to M.2 I don't know if it's worth the trouble (and money) given that on my computer running from SATA3 disks or RAMdisk doesn't seem like it's making any difference. And RAM is much faster than M.2 too. Just out of curiosity, how many "AVG triples/seconds" can you get with your server-class hardware when converting a .nt to TDB2 using tdb2.tdbloader?
