Horrendous performance due to disk activity

[NXMold]

I've been watching various performance meters to try and find the bottleneck because NX 7.5.0.32 64-bit is too slow for my liking (not surprising, I'm tremendously impatient).

My system specs: core i7 930 overclocked to 3.2Ghz, 6gb 1333Mhz, Patriot Torx SSD, quadro fx580, win7-64. Its no slouch of a system.

I recently set UGII_SMP_ENABLE = 1 but have not seen any benefit.

Memory utilization has been around 50-65%, processor only 1-2% (!) typically, up to 13% during some operations, and the big one, hard disk 100% activity for tens of minutes at a time.

And thats really horribly bad. Especially since windows does not seem to multi-task at all when it comes to disk activity, 100% utilization brings down the whole system. Oddly, this disk activity seems to occur when modifying fully loaded parts in addition to opening or saving.

Using the ATTO benchmark tool shows 150 MBps write speeds and 200 MBps reads with large files (confirmed by watching the windows resource monitor). So thats the best-case observed performance of my hard disk.

While NX is bogging down the disk, the windows resource monitor graph stays below 10 MBps. Re-running ATTO several times, I tried adjusting the settings to emulate NX. I accomplished this by only writing files 0.5-1 kilobytes in size, if I write 2kb files performance shoots up to 30MBps+. Therefore I believe that the HUGE disk performance penalty I'm observing in NX is due to reading/writing many VERY small files to disk.

I normally use partial loading. My assembly is 292 files and 890Mb total size, 240 of the files are under 1Mb, the smallest are 16kb. I tried opending the assembly without using partial loading, then performing an update that was previously quite slow and created tons of disk activity. Resource utilization results are the same, 1% cpu, 59% memory, 100% disk at 3 MBps. This edit (re-sizing a single radius thats wave linked through three other components) takes more than five minutes, and its not particularly unique.

The problem does not seem to be related to loading models, so I'm suspecting its temp files of some sort? The resource monitor shows the ugraf.exe process and the system process both with loads of disk activity. Could this be swap-file activity even though I'm only using 3.7 GB out of 6 GB of memory? I don't know how to dive in any deeper than this, I'm at a dead-end. Any ideas?

NX 7.5.0.32 MoldWizard

 

[NXMold]

Update: I copied my models to a network share (gbit lan 75 MBps+ benchmark performance on the share) and tried the same edit.

It took only seconds to complete, compared to 5+ minutes when the files were local. Interestingly though, disk activity still spiked to 100% at around 3 MBps. Strange indeed.


NX 7.5.0.32 MoldWizard

 

[cowski]

Are you loading all these files from the SSD or is there also a conventional hard drive and/or network drives involved?

I don't know much about the Patriot SSD that you mention, but I do know that not all SSD's are created equal and that some can actually be slower than a conventional hard drive.

More CPU cycles won't help if you can't feed your CPU fast enough.

 

[NXMold]

The SSD is my only local hard drive, single partition. This model had very good reviews from the tech rags, it seems to be known as one of the premium models.

Windows, NX, and models are all local.

NX 7.5.0.32 MoldWizard

 

[cowski]

Maybe you need a driver or BIOS update for optimum performance?

 

[tryitagain]

Hi NXMold,

I got the same experince with the SMP. But I do not know very much about hardware. Is there a difference in having a multiple core processor to having multiple processors?
I remember when I bought new hardware in the past, I always did a performance comparison between enabled and disabled SMP. The test was always an update of a few drawings of a mold design. The last test I did was without SMP 32 min abd with SMP 18 min.
With the multiple core machine I do not see any difference at all.

Regards,

 

[NXMold]

I found the files, dozens and dozens of files being written to C:\Users\[username]\AppData\Local\Temp with file names like tmor71E1dp9j.rol_bin ranging in size mostly from 20-200 kb, with some as large as 1.5mb. The system process, not ugraf, is creating these files.

I'm sure this is the problem point. Can I re-direct these to another drive?

NX 7.5.0.32 MoldWizard

 

[JohnRBaker]

Yes, you can set the variable...

UGII_UGSOLIDS_TMP=

...to where you would like the .rol_bin files to be directed. These are temporary files used to support Undo and other Parasolid operations and are indeed generated by NX, but at a very low level. It's recommended that this location be on your local drive for maximum performance.

Note that this variable can be set either in your user profile, your start-up file, if you launch NX in that manner, or in the 'ugii_env.dat' file. If you do NOT set this variable, the .rol_bin files will be directed to the ...\local\temp folder.

That being said, I'm looking into is there are anything special that can be done about your situation and I'll get back to you if I learn something more.

John R. Baker, P.E.
Product 'Evangelist'
Product Design Solutions
Siemens PLM Software Inc.
Industry Sector
Cypress, CA

http://www.siemens.com/plm

http://www.plmworld.org/museum/

To an Engineer, the glass is twice as big as it needs to be.

 

[NXMold]

Excellent, thanks John. I'm going to expieriement with the temp file location and see if I can discover anything useful.

NX 7.5.0.32 MoldWizard

 

[fmr110]

Didn't I hear something somewhere on these forums about NX not running well on Windows 7?

I'd be curious to see if there was any difference if you ran it in WINXP.

 

[JohnRBaker]

OK, I got some feedback on a couple of things that you can do which may help you some.

First, make sure that you've set your 'Features/Mark' setting to something reasonable.

Now if you don't know what this is, it's a scheme which allows you to update your models faster since once you've done an initial update of the model history, the next time you make an edit during your session, the model will not have to roll-back as far to start the update process. The 'Features/Mark' setting controls the granularity of this behavior. That is it controls how big are the 'steps' in the update. This option is set at...

Customer Defaults -> Modeling -> General -> Update

...the first item on the page.

Now the rule of thumb is that if your typical model has 10's of features, set this mark to 1. If the typical model has 100's of features, set it to 10, but if the typical model has 1000's of features, set this to 100. If you set it too low, then extra .rol_bin files are created as you open and update your models. Note that I've actually tested this and changing from 1 to 10, or 10 to 100, 'Features/Mark' can have a significant impact on the number of .rol_bin files created.

The second thing that you can do is a bit more counterintuitive (note that I've not been able to verify this, but our architecture people say that it can have an impact).

There's something called the 'Undo File Size'. This is set at...

Customer Defaults -> Gateway -> General -> Undo

Now it would seem that setting this to a larger size would be better, and normally it is as this helps to keep memory usage to a lower level, but it appears that if you set this value TOO large it could cause additional .rol_bin files to be created. Note that I've set mine to 1024Mb, which seems to be a reasonable place to start.

Anyway, I would at least look into the first recommendation above as I think that will have the biggest impact and is also the one which is most likely abused in the sense that some people will think that the absolute best setting is always 1, which is really not the case when you take everything into consideration.

John R. Baker, P.E.
Product 'Evangelist'
Product Design Solutions
Siemens PLM Software Inc.
Industry Sector
Cypress, CA

http://www.siemens.com/plm

http://www.plmworld.org/museum/

To an Engineer, the glass is twice as big as it needs to be.

 

[NXMold]

Wow! I'm back to being processor bound wtih negligable disk activity after moving that path to a fast network share. MUCH FASTSER. But lets put some numbers to that feeling:

Test A) Open top assy 'structure only', select the entire assembly, then measure the time it takes to "Open Component Fully".

Test B) Next, change work part to core slides and change the value for the last feature resize blend from .425 to .300, ignore the time. Change it back to .425 measuring time until animated NX activity icon dissapears.

Scenario 1) UG parts on network drive U, UGII_UGSOLIDS_TMP on local disk.

Scenario 1b) Same as 1, but changed "Customer Defaults -> Modeling -> General -> Update -> Features/Mark" from the default 1 to 15.

Scenario 2) UG parts on network drive U, UGII_UGSOLIDS_TMP on network drive P.

Scenario 2b) Same as 2, but changed "Customer Defaults -> Modeling -> General -> Update -> Features/Mark" from the default 1 to 15.

Results:
A B
1) 8:37 (10:03) 4:40 (5:56)
1b) 3:59 (4:22) 0:37 (0:50)

2) 3:41 1:00
2b) 3:16 0:34

*(0:00) time when the hard drive activity light finally went out and the system became completely available again. This is clearly the write-cache at work.

I did not change the undo-file-size since its not clear what I should try, and I'm getting a little tired of playing with the stopwatch.

That features/mark setting created a MASSIVE improvement and is definately something everyone should adjust, no?

NX 7.5.0.32 MoldWizard

 

[JohnRBaker]

Yes, we would recommend that everyone review their 'Features/Mark' Customer Default setting and that they consider changing it based on my previous suggested 'rule-of-thumb'.

John R. Baker, P.E.
Product 'Evangelist'
Product Design Solutions
Siemens PLM Software Inc.
Industry Sector
Cypress, CA

http://www.siemens.com/plm

http://www.plmworld.org/museum/

To an Engineer, the glass is twice as big as it needs to be.

 

[NXMold]

fmr110, this problem existed when I was using XP too. I just upgraded my workstation to windows 7 a couple weeks ago and the situation is the same.

I appears this problem is aggravated by the SSD drive, but does exist on conventional drives as well. I decided to do another test using a 1.5 Gb ramdisk (Siemens may not think this data belongs in volitile memory, but I do!).

Scenario 3) UG parts on network drive U, UGII_UGSOLIDS_TMP on RAMDISK, Features/Mark = 15.

3) 2:42 0:29

Unsuprisingly the fastest time yet. John, do you have any idea how large this temp location needs to be? I'll need to upgrade to 12gb of ram if I stick with the ramdrive, but for the performance I'm seing it would be well worth the $180 investment.

NX 7.5.0.32 MoldWizard

 

[JohnRBaker]

The files are automatically deleted as soon as you close your session so it's not like it accumulates. That being said, I've never heard of anyone running out of space for their .rol_bin files but I suppose it could happen.

John R. Baker, P.E.
Product 'Evangelist'
Product Design Solutions
Siemens PLM Software Inc.
Industry Sector
Cypress, CA

http://www.siemens.com/plm

http://www.plmworld.org/museum/

To an Engineer, the glass is twice as big as it needs to be.

 

[JonSelby]

Could RAM usage be contributing here? I know that in XP any one program can only take upto 2GB of RAM and there is a 3GB 'switch' that you can enable.
I believe the 3GB 'switch' is also available Windows 7 but have not looked into how this works.

Could it be that one of the processes contributing to your 3.7GB usage is limited to 2GB and would benefit from being able to use 3GB?

Note: I've not tried this 'switch' myself and have been warned about the BSOD!

 

[cowski]

The 3GB switch doesn't apply to a 64 bit OS running a 64 bit app.

 

[JonSelby]

Cheers cowski ... that makes sense!