Hi There

We run zOSMF V3.1 on 8-way parallel sysplex with shared zFS. We have an small network team that have been using the Network Configuration Assistant  NCA plug-in successfully for a number of years. We also have a community of  dev ops users developing applications using REST services via cli and zowe. 

Over the last few weeks the NCA have started complaining of poor response with the zOSMF gui in general, and with the NCA plug-in in particular, to the extent that it can take several minutes to retrieve a backing store, and the app frequently times out when retrieving routing information. The dev ops team do not use the gui so have not expressed any such problems. 

We are trying to get a handle on the origin of this performance bottleneck.  The performance team have said that the IZUSVR1 task is not resource constrained. We have checked and the file owner f the zOSMF ZFS is the system where where the IZUSVR1 task runs  (we've had performance problems in the past when the two differ). The zOS is approx 30,000 tracks in size split over several extents.   We have looked at the usagestatistics app, but as the counters appear to reset to zero folowing an IPL or recycle of the zOSMF server, this is of limited use as we have no trend or baseline as to what is 'normal' usage. Furthermore, it is difficult to understand just 'how' the dev ops team are 'using' the system.  

Has anyone any experience of tuning zOSMF - or gaining insight into the internal performance - either using third-party products eg Omegamon, or standalone ?  Is java likely to be a constraining factor - or zFS size? We have raised a case with IBM but have not had much back yet in the way of insight. In the worst case, we could set up a separate instance for the dev ops team, I suppose, but we would not ideally want to down that route from an operability perspective. 

TIA

Martin

Hi There

We run zOSMF V3.1 on 8-way parallel sysplex with shared zFS. We have an small network team that have been using the Network Configuration Assistant  NCA plug-in successfully for a number of years. We also have a community of  dev ops users developing applications using REST services via cli and zowe. 

Over the last few weeks the NCA have started complaining of poor response with the zOSMF gui in general, and with the NCA plug-in in particular, to the extent that it can take several minutes to retrieve a backing store, and the app frequently times out when retrieving routing information. The dev ops team do not use the gui so have not expressed any such problems. 

We are trying to get a handle on the origin of this performance bottleneck.  The performance team have said that the IZUSVR1 task is not resource constrained. We have checked and the file owner f the zOSMF ZFS is the system where where the IZUSVR1 task runs  (we've had performance problems in the past when the two differ). The zOS is approx 30,000 tracks in size split over several extents.   We have looked at the usagestatistics app, but as the counters appear to reset to zero folowing an IPL or recycle of the zOSMF server, this is of limited use as we have no trend or baseline as to what is 'normal' usage. Furthermore, it is difficult to understand just 'how' the dev ops team are 'using' the system.  

Has anyone any experience of tuning zOSMF - or gaining insight into the internal performance - either using third-party products eg Omegamon, or standalone ?  Is java likely to be a constraining factor - or zFS size? We have raised a case with IBM but have not had much back yet in the way of insight. In the worst case, we could set up a separate instance for the dev ops team, I suppose, but we would not ideally want to down that route from an operability perspective. 

TIA

Martin

Hi There

We run zOSMF V3.1 on 8-way parallel sysplex with shared zFS. We have an small network team that have been using the Network Configuration Assistant  NCA plug-in successfully for a number of years. We also have a community of  dev ops users developing applications using REST services via cli and zowe. 

Over the last few weeks the NCA have started complaining of poor response with the zOSMF gui in general, and with the NCA plug-in in particular, to the extent that it can take several minutes to retrieve a backing store, and the app frequently times out when retrieving routing information. The dev ops team do not use the gui so have not expressed any such problems. 

We are trying to get a handle on the origin of this performance bottleneck.  The performance team have said that the IZUSVR1 task is not resource constrained. We have checked and the file owner f the zOSMF ZFS is the system where where the IZUSVR1 task runs  (we've had performance problems in the past when the two differ). The zOS is approx 30,000 tracks in size split over several extents.   We have looked at the usagestatistics app, but as the counters appear to reset to zero folowing an IPL or recycle of the zOSMF server, this is of limited use as we have no trend or baseline as to what is 'normal' usage. Furthermore, it is difficult to understand just 'how' the dev ops team are 'using' the system.  

Has anyone any experience of tuning zOSMF - or gaining insight into the internal performance - either using third-party products eg Omegamon, or standalone ?  Is java likely to be a constraining factor - or zFS size? We have raised a case with IBM but have not had much back yet in the way of insight. In the worst case, we could set up a separate instance for the dev ops team, I suppose, but we would not ideally want to down that route from an operability perspective. 

TIA

Martin