[Nicolas Saumande]

Hi,

Is there any recurring actions that can be done in order to assure the stability and the performance of the Automator servers ?
(Like deleting file logs, stoping and starting the servers, ...)

Right now, we have none defined on our environement.
And it seems that the opspserver process is taking more cpu that before. (I'm not sure of that though...)

For exemple, in our development environnement, we have 4 instances runing. Each of them is lunching a job every 30 seconds. (very short job)
And I can see the opspserver taking 100% for nearly 10 seconds, then stoping for around 7 seconds, and going on again.

So I was thinking that maybe some actions could be done in order to purge datas that could slow down the execution of the production server ?

Thanks for your help !

Nicolas

[Ludo]

Hi Nicolas,

I believe it is difficult to answer to your question easily. In fact it is depending on your production, your OS, the database, number of user connected, number of PS, complexity of your charts, etc.

However I suppose we can say this product must be administrate (like all software); all users must not have admin rights if it is not necessary, use contexts, use view functionality, lock root access with context, etc. Thanks to these first actions, product should be more secured.

Then some points have to be checked on all production servers: Instances status (damaged instances must be erased), number of statistic and log files (which can be removed), space on file system, CPU/memory allocated to Automator, processus and port activity (mounted or not), network activity (nslookup on DNS/reverse DNS for example), log level to 1 (level 2 is a debug level, heavier never used level 3 or 4 except may be on Axway request: PS can crash), build level (bugs are fixed or evolutions are delivered each month, I suppose 2 updates per year is a minimum),etc.

Moreover, I believe specific process has to be defined in case of issue: save logs and dyn directory, write an "issue document" (date, instance name,...), then Axway can fix easier the bug; without these files, issue can take longer to besolved (I met some case Axway does not have enough information to reproduce/understand it: case has been closed without real solution because of some missing information).

Finally, Automator has got lots of functionnalities, I think few of them are used; then charts are more complex to obtain the wanted behaviour with common objects. Moreover some evolutions can be asked to Axway, the most interesting are delivered.

[Nicolas Saumande]

Many thanks for those interesting ideas,

I think I'll go and look onto these ones :
- Instance status
- Number of statistics and log files
- Log level

I'll keep you informed.

Nicolas

[Nicolas Saumande]

Hello,

I worked a little on my actions in order to make the Automator server work well :

- Log level : No loglevel is specified in our OPSchedule.ini, so I guess level 1 is used ? (I could not find the confirmation though)

- Number of log files : Our production servers are set to automatically delete Job Logs more than 8 days. So no problem on this.

- Number of statistics files : No file is created in our production environment.

- Instance status : The only thing I know about damaged Instances is when an instance is on the production server and do not appear anymore on the modelisation server.
I know how to solve the problem by stoping and restarting the production server and deleting a few folders, but is there a way to do that with the api ?
Is there any other problem that might occurs with instances ?

Thanks,
Nicolas