Results Analysis - Intergraph Smart 3D - Installation & Upgrade - Hexagon

Intergraph Smart 3D Installation

Language
English
Product
Intergraph Smart 3D
Search by Category
Installation & Upgrade
Smart 3D Version
13

The classical way to analyze database activity is to analyze the activity generated by each command (place an order, repeat order, order status, and so on) and extrapolate the response of the system to a given load. For example, if placing an order causes one physical read on the data file disk, the maximum number of orders that can be placed in one minute can be computed.

Given the huge number of commands that exist in the software, this approach is not practical for our system. Instead, the focus is placed on measuring the typical activity per interactive user for a given environment. Getting reliable average data requires having several users working concurrently. The data generated by a single interactive user is usually too noisy to be used.

After the data is collected for a given load, the response of the system can be extrapolated to a higher load assuming a linear response up to a critical value. Refer to Microsoft SQL Server or Oracle performance tuning documentation for more details.

Example

The following graphic shows some of the system parameters while two users are routing pipes and two users are creating beams in structure:

Average CPU usage

15%

Reads per second ModelDB data

0.003

Writes per second ModelDB data

2.75

Read per second ModelDB log

0.003

Write per second ModelDB log

2.83

Reads per second C drive

0.12

Writes per second C drive

2.50

Batch per second

290

CPU

  • CPU capacity = 2 (processors) ´ 500 MHz = 1 GHz

  • CPU usage per user = CPU capacity ´ (average CPU % used / number of users) = 1 GHz ´ .15/4 users = approximately .0375 GHz per user

Therefore, for a single 1.0 GHz processor:

  • Usage capacity = 1.0 GHz ´ .75 (critical usage percentage or usable capacity)

  • Number of users = Usable capacity / CPU usage per user

The system should support (0.75/0.0375) GHz per user = 20 users per GHz.

Model Data File

  • Total physical I/O per second = 2.75 (Model DB writes) + 0.003 (Model DB reads) = 2.75 physical I/O per second for 4 users = approximately 0.69 physical I/O per second per user

  • Ignoring RAID factor and taking a standard Max I/O = 70 ´ 75% = 52

Therefore, using the same disk characteristics, can support 59/0.68 = 75 users per disk.

Model Log File

  • Total physical I/O per second = 2.83 (ModelDB writes) + 0.003 (ModelDB reads) = 2.83 physical I/O per second for 4 users

  • Ignoring RAID factor and taking a standard Max I/O = 70 ´ 75% = 52.

Therefore, using the same disk characteristics, can support 52/0.71 = 73 users per disk.

  • Testing has determined that the main hardware parameters driving the scalability of the system are the CPU and the I/Os.

  • A system different than the one used for testing purposes can lead to completely different results. For example, if the memory is scarce, more loads are placed on the I/O system.

  • Because the log file I/Os are mostly sequential, the system can achieve about 150 sequential I/Os per second per physical disk, compared with only 50 random I/Os per second per physical disk.

Other Considerations

Interference Checking (IFC)

IFC imposes a very significant load on the database server (equivalent to several simultaneous interactive users). We recommend turning off IFC to measure the database activity generated by the interactive users using the design applications (piping, structure, and so on).

Reports

Some reports can put a heavy burden on the server. Hexagon Asset Lifecycle Intelligence advises monitoring the reports activity separately from the database activity generated by the interactive users using design applications (piping, structure, and so on).

See Also

Recommendation for Database Monitoring