So I've been limping along with the 6.3.2 OVA based install running on a Dual CPU Athlon based ESX box with 16 Gig RAM. I gave the single node VM 12 Gig of RAM and the install went OK. Res Mgr starts OK, load shoots up and then levels off. I've been able to add devices and kick the tires a bit. I ran a discovery of my home lab and everything went into /Discovered as advertised. Today I moved a Win7 labptop into /Server/Windows and did a "model" and load shot up sky high. What 'woke up' when I did this? Attaching a screen shot of top.
| Subject: |
RE: ISO vs OVA Installation Question |
| Author: |
Michael Rogers |
| Posted: |
2021-06-04 19:03 |
Rob,
Kicking off a model job is going to result in a fair number of things happening. I'll start by assuming you're doing this from the command line.
1. Zenmodeler is going to start up, which will require loading the modeler Python code from disk, along with its various imports.
2. Once zenmodeler is started, it'll reach out to zenhub to get its marching orders.
3. Zenhub will need to pull back data about the device, any configured zProperties required to get into the device, and a list of modeler plugins to run. This data is going to come from memcached, primarily. If the required data isn't currently cached, it'll need to make calls to the Solr index.
4. Once this data is sent back to zenmodeler, it will load additional code from zenhub along with the modeler plugin Python files from disk.
5. At this point, the actual model job should commence and exist only in memory.
6. When the model job is complete, the assembled model data will be handed back to zenhub for addition to its worklist.
7. A zenhub worker will then execute an "applyDataMaps" task which consists of writing the model data to the zodb database (in the mariadb-model container) and indexing the data with Solr.
If the model job was initiated from the GUI, all of the above steps will be executed by the zminion service which adds a tiny bit more load.
All told, I'd bet a dollar that a load that high is pointing toward an I/O issue. If you can, I'd recommend pulling up iostat and then fire off another model job to see what gets reported. It's also simply possible that, with so few cores, the model adds one too many more things that all need to happen at the same time and we're seeing a fist-fight for run time.
Let me know what you find?
PS: the dollar I wagered above is a hypothetical dollar and does not constitute a contract. Also, I don't have a Venmo or PayPal account, anyway. ;)
------------------------------
Michael J. Rogers
Senior Instructor - Zenoss
Austin TX
------------------------------
