This is an archive of the Maximo Yahoo Community. The content of this pages may be a sometimes obsolete so please check post dates.
Thanks to the community owner Christopher Wanko for providing the content.
Working with a customer (MAM7.5, SQL2k8r2, WAS) that is seeing incredibly slow WO closing times in the 12-20 second range.
Some of these are PM WOs with upwards of 50 tasks, which had us thinking that closing each task was the issue. Problem is, even on smaller PMs (3-10 tasks) we're getting the same performance.
I've not been involved with the performance tuning of Maximo to this point, mainly the implementation and upgrades portion, but I no longer have a performance guy to lean on right now.
Any thoughts?
CJ Stringer
Perhaps this is a hardware/network related issue?
On Jan 26, 2012, at 9:55 AM, Chad Stringer <cstringer@practive-inc.com> wrote:
> Working with a customer (MAM7.5, SQL2k8r2, WAS) that is seeing incredibly slow WO closing times in the 12-20 second range.
> Some of these are PM WOs with upwards of 50 tasks, which had us thinking that closing each task was the issue. Problem is, even on smaller PMs (3-10 tasks) we're getting the same performance.
> I've not been involved with the performance tuning of Maximo to this point, mainly the implementation and upgrades portion, but I no longer have a performance guy to lean on right now.
>
> Any thoughts?
>
> CJ Stringer
>
>
>
>
Hi,
After you upgraded or imported the data did you rebuild the indexes? We conslidated eight separate installations into one and after every site we rebuilt the indexes. It made a vast improvement on performance.
Ask your DB admin.
Dave Bone
--- In MAXIMO@yahoogroups.com, Chad Stringer <cstringer@...> wrote:
>
> Working with a customer (MAM7.5, SQL2k8r2, WAS) that is seeing incredibly slow WO closing times in the 12-20 second range.
> Some of these are PM WOs with upwards of 50 tasks, which had us thinking that closing each task was the issue. Problem is, even on smaller PMs (3-10 tasks) we're getting the same performance.
> I've not been involved with the performance tuning of Maximo to this point, mainly the implementation and upgrades portion, but I no longer have a performance guy to lean on right now.
>
> Any thoughts?
>
> CJ Stringer
>
>
>
>
>
That's part of what is confusing us. We've rebuilt the indexes, have the Websphere/Maximo server up to 6GB RAM (way overkill) and the SQL Server is separate on an instance with only 4 other prod DBs with 16GB RAM allocated. App box is a Quad core box and the SQL Server is 16 cores.
System is not maxing the RAM in the process, and the DB server isn't close to peaking.
CJ Stringer
From: MAXIMO@yahoogroups.com [mailto:MAXIMO@yahoogroups.com] On Behalf Of in2data
Sent: Thursday, January 26, 2012 7:09 PM
To: MAXIMO@yahoogroups.com
Subject: [MAXIMO List] Re: Extensive WO closing times
Hi,
After you upgraded or imported the data did you rebuild the indexes? We conslidated eight separate installations into one and after every site we rebuilt the indexes. It made a vast improvement on performance.
Ask your DB admin.
Dave Bone
--- In MAXIMO@yahoogroups.com<mailto:MAXIMO%40yahoogroups.com>, Chad Stringer <cstringer@...<mailto:cstringer@...>> wrote:
>
> Working with a customer (MAM7.5, SQL2k8r2, WAS) that is seeing incredibly slow WO closing times in the 12-20 second range.
> Some of these are PM WOs with upwards of 50 tasks, which had us thinking that closing each task was the issue. Problem is, even on smaller PMs (3-10 tasks) we're getting the same performance.
> I've not been involved with the performance tuning of Maximo to this point, mainly the implementation and upgrades portion, but I no longer have a performance guy to lean on right now.
>
> Any thoughts?
>
> CJ Stringer
>
>
>
>
>
I'm curious about 6gb being "way overkill". We run 24gb on our production application server and I only consider that slight overkill (room to grow I like to call it). The memory you need will be largely dependent on your configuration. Are you running a 64bit OS? How many JVMs? Last recommendation I saw from IBM for a 64bit OS was to set the max heap size to 2.5gb, so if you're even running just 2 JVMs, 6gb is not sufficient. If you are running a single JVM, maybe that is part of the problem. How many concurrent users do you typically have? Do you run a lot of CRON jobs and/or MIF processes. These are all things that need to be considered when determining hardware needs and how many JVMs to run.
Have you looked at the memory profile in WebShpere or in the logs to see if the heap size is getting maxed out? Do you have custom code in your system? From what you've said so far it sounds like you're not even sure if the bottleneck is on the application or DB side. You might want to try setting mxe.db.logSQLTimeLimit so that any SQL that takes a long time to come back from the DB gets logged. That might at least narrow down where you should be looking.
Hope that helps a little bit.
-Chris H
-----Original Message-----
From: MAXIMO@yahoogroups.com [mailto:MAXIMO@yahoogroups.com] On Behalf Of Chad Stringer
Sent: Thursday, January 26, 2012 8:09 PM
To: MAXIMO@yahoogroups.com
Subject: RE: [MAXIMO List] Re: Extensive WO closing times
That's part of what is confusing us. We've rebuilt the indexes, have the Websphere/Maximo server up to 6GB RAM (way overkill) and the SQL Server is separate on an instance with only 4 other prod DBs with 16GB RAM allocated. App box is a Quad core box and the SQL Server is 16 cores.
System is not maxing the RAM in the process, and the DB server isn't close to peaking.
CJ Stringer
From: MAXIMO@yahoogroups.com <mailto:MAXIMO%40yahoogroups.com> [mailto:MAXIMO@yahoogroups.com <mailto:MAXIMO%40yahoogroups.com> ] On Behalf Of in2data
Sent: Thursday, January 26, 2012 7:09 PM
To: MAXIMO@yahoogroups.com <mailto:MAXIMO%40yahoogroups.com>
Subject: [MAXIMO List] Re: Extensive WO closing times
Hi,
After you upgraded or imported the data did you rebuild the indexes? We conslidated eight separate installations into one and after every site we rebuilt the indexes. It made a vast improvement on performance.
Ask your DB admin.
Dave Bone
--- In MAXIMO@yahoogroups.com <mailto:MAXIMO%40yahoogroups.com> <mailto:MAXIMO%40yahoogroups.com>, Chad Stringer <cstringer@...<mailto:cstringer@...>> wrote:
>
> Working with a customer (MAM7.5, SQL2k8r2, WAS) that is seeing incredibly slow WO closing times in the 12-20 second range.
> Some of these are PM WOs with upwards of 50 tasks, which had us thinking that closing each task was the issue. Problem is, even on smaller PMs (3-10 tasks) we're getting the same performance.
> I've not been involved with the performance tuning of Maximo to this point, mainly the implementation and upgrades portion, but I no longer have a performance guy to lean on right now.
>
> Any thoughts?
>
> CJ Stringer
>
>
>
>
>
Chris,
Thanks for the ideas.
We currently run 1 JVM, 64bit. I do not have access to the WAS console, so I will check with that team on the settings.
Max user in the system is very low, between 4-5. Very low usage by users, but a lot of transactions. No custom code (java/class mods).
Base cron tasks, don't even generate PMs from a cron task at this point. No MIF integrations.
I'll look into the mxe.db.logSQLTimeLimit setting and see what I can find.
Do I need to be monitoring live when these transactions occur?
Thanks again.
CJ
From: MAXIMO@yahoogroups.com [mailto:MAXIMO@yahoogroups.com] On Behalf Of Hanna, Christopher CTR
Sent: Friday, January 27, 2012 8:24 AM
To: MAXIMO@yahoogroups.com
Subject: RE: [MAXIMO List] Re: Extensive WO closing times
I'm curious about 6gb being "way overkill". We run 24gb on our production application server and I only consider that slight overkill (room to grow I like to call it). The memory you need will be largely dependent on your configuration. Are you running a 64bit OS? How many JVMs? Last recommendation I saw from IBM for a 64bit OS was to set the max heap size to 2.5gb, so if you're even running just 2 JVMs, 6gb is not sufficient. If you are running a single JVM, maybe that is part of the problem. How many concurrent users do you typically have? Do you run a lot of CRON jobs and/or MIF processes. These are all things that need to be considered when determining hardware needs and how many JVMs to run.
Have you looked at the memory profile in WebShpere or in the logs to see if the heap size is getting maxed out? Do you have custom code in your system? From what you've said so far it sounds like you're not even sure if the bottleneck is on the application or DB side. You might want to try setting mxe.db.logSQLTimeLimit so that any SQL that takes a long time to come back from the DB gets logged. That might at least narrow down where you should be looking.
Hope that helps a little bit.
-Chris H
-----Original Message-----
From: MAXIMO@yahoogroups.com<mailto:MAXIMO%40yahoogroups.com> [mailto:MAXIMO@yahoogroups.com<mailto:MAXIMO%40yahoogroups.com>] On Behalf Of Chad Stringer
Sent: Thursday, January 26, 2012 8:09 PM
To: MAXIMO@yahoogroups.com<mailto:MAXIMO%40yahoogroups.com>
Subject: RE: [MAXIMO List] Re: Extensive WO closing times
That's part of what is confusing us. We've rebuilt the indexes, have the Websphere/Maximo server up to 6GB RAM (way overkill) and the SQL Server is separate on an instance with only 4 other prod DBs with 16GB RAM allocated. App box is a Quad core box and the SQL Server is 16 cores.
System is not maxing the RAM in the process, and the DB server isn't close to peaking.
CJ Stringer
From: MAXIMO@yahoogroups.com<mailto:MAXIMO%40yahoogroups.com> <mailto:MAXIMO%40yahoogroups.com> [mailto:MAXIMO@yahoogroups.com<mailto:MAXIMO%40yahoogroups.com> <mailto:MAXIMO%40yahoogroups.com> ] On Behalf Of in2data
Sent: Thursday, January 26, 2012 7:09 PM
To: MAXIMO@yahoogroups.com<mailto:MAXIMO%40yahoogroups.com> <mailto:MAXIMO%40yahoogroups.com>
Subject: [MAXIMO List] Re: Extensive WO closing times
Hi,
After you upgraded or imported the data did you rebuild the indexes? We conslidated eight separate installations into one and after every site we rebuilt the indexes. It made a vast improvement on performance.
Ask your DB admin.
Dave Bone
--- In MAXIMO@yahoogroups.com<mailto:MAXIMO%40yahoogroups.com> <mailto:MAXIMO%40yahoogroups.com> <mailto:MAXIMO%40yahoogroups.com>, Chad Stringer <cstringer@...<mailto:cstringer@...<mailto:cstringer@...%3cmailto:cstringer@...>>> wrote:
>
> Working with a customer (MAM7.5, SQL2k8r2, WAS) that is seeing incredibly slow WO closing times in the 12-20 second range.
> Some of these are PM WOs with upwards of 50 tasks, which had us thinking that closing each task was the issue. Problem is, even on smaller PMs (3-10 tasks) we're getting the same performance.
> I've not been involved with the performance tuning of Maximo to this point, mainly the implementation and upgrades portion, but I no longer have a performance guy to lean on right now.
>
> Any thoughts?
>
> CJ Stringer
>
>
>
>
>
For Maximo 7.5 on 64 bit IBM recommend the min and max heap be 4096m. Have your JVM parameters checked, make sure ackTimeout and the GC parameters are set in line with IBM's recommendations as these being miss configured an have a major impact, I'd say that and SQL logging should be your first checks quickly followed by analyzing the heap usage. If the JVM settings are incorrect you're likely to see excessive GC pauses and possibly heap saturation which lead very quickly to ugly performance.
Chris.
On Jan 27, 2012, at 5:47 AM, Chad Stringer <cstringer@practive-inc.com> wrote:
> Chris,
> Thanks for the ideas.
> We currently run 1 JVM, 64bit. I do not have access to the WAS console, so I will check with that team on the settings.
> Max user in the system is very low, between 4-5. Very low usage by users, but a lot of transactions. No custom code (java/class mods).
> Base cron tasks, don't even generate PMs from a cron task at this point. No MIF integrations.
>
> I'll look into the mxe.db.logSQLTimeLimit setting and see what I can find.
> Do I need to be monitoring live when these transactions occur?
>
> Thanks again.
>
> CJ
>
> From: MAXIMO@yahoogroups.com [mailto:MAXIMO@yahoogroups.com] On Behalf Of Hanna, Christopher CTR
> Sent: Friday, January 27, 2012 8:24 AM
> To: MAXIMO@yahoogroups.com
> Subject: RE: [MAXIMO List] Re: Extensive WO closing times
>
> I'm curious about 6gb being "way overkill". We run 24gb on our production application server and I only consider that slight overkill (room to grow I like to call it). The memory you need will be largely dependent on your configuration. Are you running a 64bit OS? How many JVMs? Last recommendation I saw from IBM for a 64bit OS was to set the max heap size to 2.5gb, so if you're even running just 2 JVMs, 6gb is not sufficient. If you are running a single JVM, maybe that is part of the problem. How many concurrent users do you typically have? Do you run a lot of CRON jobs and/or MIF processes. These are all things that need to be considered when determining hardware needs and how many JVMs to run.
>
> Have you looked at the memory profile in WebShpere or in the logs to see if the heap size is getting maxed out? Do you have custom code in your system? From what you've said so far it sounds like you're not even sure if the bottleneck is on the application or DB side. You might want to try setting mxe.db.logSQLTimeLimit so that any SQL that takes a long time to come back from the DB gets logged. That might at least narrow down where you should be looking.
>
> Hope that helps a little bit.
>
> -Chris H
>
> -----Original Message-----
> From: MAXIMO@yahoogroups.com<mailto:MAXIMO%40yahoogroups.com> [mailto:MAXIMO@yahoogroups.com<mailto:MAXIMO%40yahoogroups.com>] On Behalf Of Chad Stringer
> Sent: Thursday, January 26, 2012 8:09 PM
> To: MAXIMO@yahoogroups.com<mailto:MAXIMO%40yahoogroups.com>
> Subject: RE: [MAXIMO List] Re: Extensive WO closing times
>
> That's part of what is confusing us. We've rebuilt the indexes, have the Websphere/Maximo server up to 6GB RAM (way overkill) and the SQL Server is separate on an instance with only 4 other prod DBs with 16GB RAM allocated. App box is a Quad core box and the SQL Server is 16 cores.
> System is not maxing the RAM in the process, and the DB server isn't close to peaking.
>
> CJ Stringer
> From: MAXIMO@yahoogroups.com<mailto:MAXIMO%40yahoogroups.com> <mailto:MAXIMO%40yahoogroups.com> [mailto:MAXIMO@yahoogroups.com<mailto:MAXIMO%40yahoogroups.com> <mailto:MAXIMO%40yahoogroups.com> ] On Behalf Of in2data
> Sent: Thursday, January 26, 2012 7:09 PM
> To: MAXIMO@yahoogroups.com<mailto:MAXIMO%40yahoogroups.com> <mailto:MAXIMO%40yahoogroups.com>
> Subject: [MAXIMO List] Re: Extensive WO closing times
>
> Hi,
>
> After you upgraded or imported the data did you rebuild the indexes? We conslidated eight separate installations into one and after every site we rebuilt the indexes. It made a vast improvement on performance.
>
> Ask your DB admin.
>
> Dave Bone
>
> --- In MAXIMO@yahoogroups.com<mailto:MAXIMO%40yahoogroups.com> <mailto:MAXIMO%40yahoogroups.com> <mailto:MAXIMO%40yahoogroups.com>, Chad Stringer <cstringer@...<mailto:cstringer@...<mailto:cstringer@...%3cmailto:cstringer@...>>> wrote:
> >
> > Working with a customer (MAM7.5, SQL2k8r2, WAS) that is seeing incredibly slow WO closing times in the 12-20 second range.
> > Some of these are PM WOs with upwards of 50 tasks, which had us thinking that closing each task was the issue. Problem is, even on smaller PMs (3-10 tasks) we're getting the same performance.
> > I've not been involved with the performance tuning of Maximo to this point, mainly the implementation and upgrades portion, but I no longer have a performance guy to lean on right now.
> >
> > Any thoughts?
> >
> > CJ Stringer
> >
> >
> >
> >
> >
>
>
>
>
>
>
Hi,
You don't have to monitor the logs actively but after they grow to a certain size the current log becomes the archived log and a new log starts. We have a lot of transactions so our logs only go back about 12 hours. We could increase the log size if we needed to do that.
We had an issue with the system being slow overall and we were getting a lot of SQL queries exceeding our timeout. Turned out to be a new database that had been added to the DB server was not only slowing down Maximo but all other applications using the DB server.
Dave Bone
--- In MAXIMO@yahoogroups.com, Chris Lawless <lawlessc@...> wrote:
>
> For Maximo 7.5 on 64 bit IBM recommend the min and max heap be 4096m. Have your JVM parameters checked, make sure ackTimeout and the GC parameters are set in line with IBM's recommendations as these being miss configured an have a major impact, I'd say that and SQL logging should be your first checks quickly followed by analyzing the heap usage. If the JVM settings are incorrect you're likely to see excessive GC pauses and possibly heap saturation which lead very quickly to ugly performance.
>
> Chris.
>
> On Jan 27, 2012, at 5:47 AM, Chad Stringer <cstringer@...> wrote:
>
> > Chris,
> > Thanks for the ideas.
> > We currently run 1 JVM, 64bit. I do not have access to the WAS console, so I will check with that team on the settings.
> > Max user in the system is very low, between 4-5. Very low usage by users, but a lot of transactions. No custom code (java/class mods).
> > Base cron tasks, don't even generate PMs from a cron task at this point. No MIF integrations.
> >
> > I'll look into the mxe.db.logSQLTimeLimit setting and see what I can find.
> > Do I need to be monitoring live when these transactions occur?
> >
> > Thanks again.
> >
> > CJ
> >
> > From: MAXIMO@yahoogroups.com [mailto:MAXIMO@yahoogroups.com] On Behalf Of Hanna, Christopher CTR
> > Sent: Friday, January 27, 2012 8:24 AM
> > To: MAXIMO@yahoogroups.com
> > Subject: RE: [MAXIMO List] Re: Extensive WO closing times
> >
> > I'm curious about 6gb being "way overkill". We run 24gb on our production application server and I only consider that slight overkill (room to grow I like to call it). The memory you need will be largely dependent on your configuration. Are you running a 64bit OS? How many JVMs? Last recommendation I saw from IBM for a 64bit OS was to set the max heap size to 2.5gb, so if you're even running just 2 JVMs, 6gb is not sufficient. If you are running a single JVM, maybe that is part of the problem. How many concurrent users do you typically have? Do you run a lot of CRON jobs and/or MIF processes. These are all things that need to be considered when determining hardware needs and how many JVMs to run.
> >
> > Have you looked at the memory profile in WebShpere or in the logs to see if the heap size is getting maxed out? Do you have custom code in your system? From what you've said so far it sounds like you're not even sure if the bottleneck is on the application or DB side. You might want to try setting mxe.db.logSQLTimeLimit so that any SQL that takes a long time to come back from the DB gets logged. That might at least narrow down where you should be looking.
> >
> > Hope that helps a little bit.
> >
> > -Chris H
> >
> > -----Original Message-----
> > From: MAXIMO@yahoogroups.com<mailto:MAXIMO%40yahoogroups.com> [mailto:MAXIMO@yahoogroups.com<mailto:MAXIMO%40yahoogroups.com>] On Behalf Of Chad Stringer
> > Sent: Thursday, January 26, 2012 8:09 PM
> > To: MAXIMO@yahoogroups.com<mailto:MAXIMO%40yahoogroups.com>
> > Subject: RE: [MAXIMO List] Re: Extensive WO closing times
> >
> > That's part of what is confusing us. We've rebuilt the indexes, have the Websphere/Maximo server up to 6GB RAM (way overkill) and the SQL Server is separate on an instance with only 4 other prod DBs with 16GB RAM allocated. App box is a Quad core box and the SQL Server is 16 cores.
> > System is not maxing the RAM in the process, and the DB server isn't close to peaking.
> >
> > CJ Stringer
> > From: MAXIMO@yahoogroups.com<mailto:MAXIMO%40yahoogroups.com> <mailto:MAXIMO%40yahoogroups.com> [mailto:MAXIMO@yahoogroups.com<mailto:MAXIMO%40yahoogroups.com> <mailto:MAXIMO%40yahoogroups.com> ] On Behalf Of in2data
> > Sent: Thursday, January 26, 2012 7:09 PM
> > To: MAXIMO@yahoogroups.com<mailto:MAXIMO%40yahoogroups.com> <mailto:MAXIMO%40yahoogroups.com>
> > Subject: [MAXIMO List] Re: Extensive WO closing times
> >
> > Hi,
> >
> > After you upgraded or imported the data did you rebuild the indexes? We conslidated eight separate installations into one and after every site we rebuilt the indexes. It made a vast improvement on performance.
> >
> > Ask your DB admin.
> >
> > Dave Bone
> >
> > --- In MAXIMO@yahoogroups.com<mailto:MAXIMO%40yahoogroups.com> <mailto:MAXIMO%40yahoogroups.com> <mailto:MAXIMO%40yahoogroups.com>, Chad Stringer <cstringer@<mailto:cstringer@<mailto:cstringer@%3cmailto:cstringer@>>> wrote:
> > >
> > > Working with a customer (MAM7.5, SQL2k8r2, WAS) that is seeing incredibly slow WO closing times in the 12-20 second range.
> > > Some of these are PM WOs with upwards of 50 tasks, which had us thinking that closing each task was the issue. Problem is, even on smaller PMs (3-10 tasks) we're getting the same performance.
> > > I've not been involved with the performance tuning of Maximo to this point, mainly the implementation and upgrades portion, but I no longer have a performance guy to lean on right now.
> > >
> > > Any thoughts?
> > >
> > > CJ Stringer
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> >
> >
>
>
>
>
Hi CJ:
Have had a similar issues with slow work order closes. This on Maximo 7.5 over Windows 2003 Server with MS SQL 2008.
Traced it with the error logs to a item reservations issue. The logs showed a huge number of SQL statements being generated concurently with the work order close. Maximo was gobbling up resources trying to clear inventory reservations. In a few cases Maximo would slowly grind to a halt as the SQL overwhelmed the server and cascading failures caused server lock up.
Based on the above we tried the inventory application, --> select Actions --> update reservations to find the reservations for the work order, then deleted the reservations. After deleting the reservations the work orders closed in ten seconds or so.
Until IBM comes up with a bug fix, or we find a better work around, we plan to use this procedure to complete WO's with Items on the planned material tab.
Good luck...
Rae
--- In MAXIMO@yahoogroups.com, "in2data" <in2data@...> wrote:
>
> Hi,
>
> You don't have to monitor the logs actively but after they grow to a certain size the current log becomes the archived log and a new log starts. We have a lot of transactions so our logs only go back about 12 hours. We could increase the log size if we needed to do that.
>
> We had an issue with the system being slow overall and we were getting a lot of SQL queries exceeding our timeout. Turned out to be a new database that had been added to the DB server was not only slowing down Maximo but all other applications using the DB server.
>
> Dave Bone
>
> --- In MAXIMO@yahoogroups.com, Chris Lawless <lawlessc@> wrote:
> >
> > For Maximo 7.5 on 64 bit IBM recommend the min and max heap be 4096m. Have your JVM parameters checked, make sure ackTimeout and the GC parameters are set in line with IBM's recommendations as these being miss configured an have a major impact, I'd say that and SQL logging should be your first checks quickly followed by analyzing the heap usage. If the JVM settings are incorrect you're likely to see excessive GC pauses and possibly heap saturation which lead very quickly to ugly performance.
> >
> > Chris.
> >
> > On Jan 27, 2012, at 5:47 AM, Chad Stringer <cstringer@> wrote:
> >
> > > Chris,
> > > Thanks for the ideas.
> > > We currently run 1 JVM, 64bit. I do not have access to the WAS console, so I will check with that team on the settings.
> > > Max user in the system is very low, between 4-5. Very low usage by users, but a lot of transactions. No custom code (java/class mods).
> > > Base cron tasks, don't even generate PMs from a cron task at this point. No MIF integrations.
> > >
> > > I'll look into the mxe.db.logSQLTimeLimit setting and see what I can find.
> > > Do I need to be monitoring live when these transactions occur?
> > >
> > > Thanks again.
> > >
> > > CJ
> > >
> > > From: MAXIMO@yahoogroups.com [mailto:MAXIMO@yahoogroups.com] On Behalf Of Hanna, Christopher CTR
> > > Sent: Friday, January 27, 2012 8:24 AM
> > > To: MAXIMO@yahoogroups.com
> > > Subject: RE: [MAXIMO List] Re: Extensive WO closing times
> > >
> > > I'm curious about 6gb being "way overkill". We run 24gb on our production application server and I only consider that slight overkill (room to grow I like to call it). The memory you need will be largely dependent on your configuration. Are you running a 64bit OS? How many JVMs? Last recommendation I saw from IBM for a 64bit OS was to set the max heap size to 2.5gb, so if you're even running just 2 JVMs, 6gb is not sufficient. If you are running a single JVM, maybe that is part of the problem. How many concurrent users do you typically have? Do you run a lot of CRON jobs and/or MIF processes. These are all things that need to be considered when determining hardware needs and how many JVMs to run.
> > >
> > > Have you looked at the memory profile in WebShpere or in the logs to see if the heap size is getting maxed out? Do you have custom code in your system? From what you've said so far it sounds like you're not even sure if the bottleneck is on the application or DB side. You might want to try setting mxe.db.logSQLTimeLimit so that any SQL that takes a long time to come back from the DB gets logged. That might at least narrow down where you should be looking.
> > >
> > > Hope that helps a little bit.
> > >
> > > -Chris H
> > >
> > > -----Original Message-----
> > > From: MAXIMO@yahoogroups.com<mailto:MAXIMO%40yahoogroups.com> [mailto:MAXIMO@yahoogroups.com<mailto:MAXIMO%40yahoogroups.com>] On Behalf Of Chad Stringer
> > > Sent: Thursday, January 26, 2012 8:09 PM
> > > To: MAXIMO@yahoogroups.com<mailto:MAXIMO%40yahoogroups.com>
> > > Subject: RE: [MAXIMO List] Re: Extensive WO closing times
> > >
> > > That's part of what is confusing us. We've rebuilt the indexes, have the Websphere/Maximo server up to 6GB RAM (way overkill) and the SQL Server is separate on an instance with only 4 other prod DBs with 16GB RAM allocated. App box is a Quad core box and the SQL Server is 16 cores.
> > > System is not maxing the RAM in the process, and the DB server isn't close to peaking.
> > >
> > > CJ Stringer
> > > From: MAXIMO@yahoogroups.com<mailto:MAXIMO%40yahoogroups.com> <mailto:MAXIMO%40yahoogroups.com> [mailto:MAXIMO@yahoogroups.com<mailto:MAXIMO%40yahoogroups.com> <mailto:MAXIMO%40yahoogroups.com> ] On Behalf Of in2data
> > > Sent: Thursday, January 26, 2012 7:09 PM
> > > To: MAXIMO@yahoogroups.com<mailto:MAXIMO%40yahoogroups.com> <mailto:MAXIMO%40yahoogroups.com>
> > > Subject: [MAXIMO List] Re: Extensive WO closing times
> > >
> > > Hi,
> > >
> > > After you upgraded or imported the data did you rebuild the indexes? We conslidated eight separate installations into one and after every site we rebuilt the indexes. It made a vast improvement on performance.
> > >
> > > Ask your DB admin.
> > >
> > > Dave Bone
> > >
> > > --- In MAXIMO@yahoogroups.com<mailto:MAXIMO%40yahoogroups.com> <mailto:MAXIMO%40yahoogroups.com> <mailto:MAXIMO%40yahoogroups.com>, Chad Stringer <cstringer@<mailto:cstringer@<mailto:cstringer@%3cmailto:cstringer@>>> wrote:
> > > >
> > > > Working with a customer (MAM7.5, SQL2k8r2, WAS) that is seeing incredibly slow WO closing times in the 12-20 second range.
> > > > Some of these are PM WOs with upwards of 50 tasks, which had us thinking that closing each task was the issue. Problem is, even on smaller PMs (3-10 tasks) we're getting the same performance.
> > > > I've not been involved with the performance tuning of Maximo to this point, mainly the implementation and upgrades portion, but I no longer have a performance guy to lean on right now.
> > > >
> > > > Any thoughts?
> > > >
> > > > CJ Stringer
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
>
In the organization settings you can elect to clear reservations when the
work order is complete rather that closed. Using this setting would
eliminate the need to manually clear out reservations before closing.
Kevin
From: MAXIMO@yahoogroups.com [mailto:MAXIMO@yahoogroups.com] On Behalf Of
Rae Simpson
Sent: Friday, January 27, 2012 8:34 PM
To: MAXIMO@yahoogroups.com
Subject: [MAXIMO List] Re: Extensive WO closing times
Hi CJ:
Have had a similar issues with slow work order closes. This on Maximo 7.5
over Windows 2003 Server with MS SQL 2008.
Traced it with the error logs to a item reservations issue. The logs showed
a huge number of SQL statements being generated concurently with the work
order close. Maximo was gobbling up resources trying to clear inventory
reservations. In a few cases Maximo would slowly grind to a halt as the SQL
overwhelmed the server and cascading failures caused server lock up.
Based on the above we tried the inventory application, --> select Actions
--> update reservations to find the reservations for the work order, then
deleted the reservations. After deleting the reservations the work orders
closed in ten seconds or so.
Until IBM comes up with a bug fix, or we find a better work around, we plan
to use this procedure to complete WO's with Items on the planned material
tab.
Good luck...
Rae
--- In MAXIMO@yahoogroups.com <mailto:MAXIMO%40yahoogroups.com> , "in2data"
<in2data@...> wrote:
>
> Hi,
>
> You don't have to monitor the logs actively but after they grow to a
certain size the current log becomes the archived log and a new log starts.
We have a lot of transactions so our logs only go back about 12 hours. We
could increase the log size if we needed to do that.
>
> We had an issue with the system being slow overall and we were getting a
lot of SQL queries exceeding our timeout. Turned out to be a new database
that had been added to the DB server was not only slowing down Maximo but
all other applications using the DB server.
>
> Dave Bone
>
> --- In MAXIMO@yahoogroups.com <mailto:MAXIMO%40yahoogroups.com> , Chris
Lawless <lawlessc@> wrote:
> >
> > For Maximo 7.5 on 64 bit IBM recommend the min and max heap be 4096m.
Have your JVM parameters checked, make sure ackTimeout and the GC parameters
are set in line with IBM's recommendations as these being miss configured an
have a major impact, I'd say that and SQL logging should be your first
checks quickly followed by analyzing the heap usage. If the JVM settings are
incorrect you're likely to see excessive GC pauses and possibly heap
saturation which lead very quickly to ugly performance.
> >
> > Chris.
> >
> > On Jan 27, 2012, at 5:47 AM, Chad Stringer <cstringer@> wrote:
> >
> > > Chris,
> > > Thanks for the ideas.
> > > We currently run 1 JVM, 64bit. I do not have access to the WAS
console, so I will check with that team on the settings.
> > > Max user in the system is very low, between 4-5. Very low usage by
users, but a lot of transactions. No custom code (java/class mods).
> > > Base cron tasks, don't even generate PMs from a cron task at this
point. No MIF integrations.
> > >
> > > I'll look into the mxe.db.logSQLTimeLimit setting and see what I can
find.
> > > Do I need to be monitoring live when these transactions occur?
> > >
> > > Thanks again.
> > >
> > > CJ
> > >
> > > From: MAXIMO@yahoogroups.com <mailto:MAXIMO%40yahoogroups.com>
[mailto:MAXIMO@yahoogroups.com <mailto:MAXIMO%40yahoogroups.com> ] On Behalf
Of Hanna, Christopher CTR
> > > Sent: Friday, January 27, 2012 8:24 AM
> > > To: MAXIMO@yahoogroups.com <mailto:MAXIMO%40yahoogroups.com>
> > > Subject: RE: [MAXIMO List] Re: Extensive WO closing times
> > >
> > > I'm curious about 6gb being "way overkill". We run 24gb on our
production application server and I only consider that slight overkill (room
to grow I like to call it). The memory you need will be largely dependent on
your configuration. Are you running a 64bit OS? How many JVMs? Last
recommendation I saw from IBM for a 64bit OS was to set the max heap size to
2.5gb, so if you're even running just 2 JVMs, 6gb is not sufficient. If you
are running a single JVM, maybe that is part of the problem. How many
concurrent users do you typically have? Do you run a lot of CRON jobs and/or
MIF processes. These are all things that need to be considered when
determining hardware needs and how many JVMs to run.
> > >
> > > Have you looked at the memory profile in WebShpere or in the logs to
see if the heap size is getting maxed out? Do you have custom code in your
system? From what you've said so far it sounds like you're not even sure if
the bottleneck is on the application or DB side. You might want to try
setting mxe.db.logSQLTimeLimit so that any SQL that takes a long time to
come back from the DB gets logged. That might at least narrow down where you
should be looking.
> > >
> > > Hope that helps a little bit.
> > >
> > > -Chris H
> > >
> > > -----Original Message-----
> > > From: MAXIMO@yahoogroups.com <mailto:MAXIMO%40yahoogroups.com>
<mailto:MAXIMO%40yahoogroups.com> [mailto:MAXIMO@yahoogroups.com
<mailto:MAXIMO%40yahoogroups.com> <mailto:MAXIMO%40yahoogroups.com>] On
Behalf Of Chad Stringer
> > > Sent: Thursday, January 26, 2012 8:09 PM
> > > To: MAXIMO@yahoogroups.com <mailto:MAXIMO%40yahoogroups.com>
<mailto:MAXIMO%40yahoogroups.com>
> > > Subject: RE: [MAXIMO List] Re: Extensive WO closing times
> > >
> > > That's part of what is confusing us. We've rebuilt the indexes, have
the Websphere/Maximo server up to 6GB RAM (way overkill) and the SQL Server
is separate on an instance with only 4 other prod DBs with 16GB RAM
allocated. App box is a Quad core box and the SQL Server is 16 cores.
> > > System is not maxing the RAM in the process, and the DB server isn't
close to peaking.
> > >
> > > CJ Stringer
> > > From: MAXIMO@yahoogroups.com <mailto:MAXIMO%40yahoogroups.com>
<mailto:MAXIMO%40yahoogroups.com> <mailto:MAXIMO%40yahoogroups.com>
[mailto:MAXIMO@yahoogroups.com <mailto:MAXIMO%40yahoogroups.com>
<mailto:MAXIMO%40yahoogroups.com> <mailto:MAXIMO%40yahoogroups.com> ] On
Behalf Of in2data
> > > Sent: Thursday, January 26, 2012 7:09 PM
> > > To: MAXIMO@yahoogroups.com <mailto:MAXIMO%40yahoogroups.com>
<mailto:MAXIMO%40yahoogroups.com> <mailto:MAXIMO%40yahoogroups.com>
> > > Subject: [MAXIMO List] Re: Extensive WO closing times
> > >
> > > Hi,
> > >
> > > After you upgraded or imported the data did you rebuild the indexes?
We conslidated eight separate installations into one and after every site we
rebuilt the indexes. It made a vast improvement on performance.
> > >
> > > Ask your DB admin.
> > >
> > > Dave Bone
> > >
> > > --- In MAXIMO@yahoogroups.com <mailto:MAXIMO%40yahoogroups.com>
<mailto:MAXIMO%40yahoogroups.com> <mailto:MAXIMO%40yahoogroups.com>
<mailto:MAXIMO%40yahoogroups.com>, Chad Stringer
<cstringer@<mailto:cstringer@<mailto:cstringer@%3cmailto:cstringer@>>>
wrote:
> > > >
> > > > Working with a customer (MAM7.5, SQL2k8r2, WAS) that is seeing
incredibly slow WO closing times in the 12-20 second range.
> > > > Some of these are PM WOs with upwards of 50 tasks, which had us
thinking that closing each task was the issue. Problem is, even on smaller
PMs (3-10 tasks) we're getting the same performance.
> > > > I've not been involved with the performance tuning of Maximo to this
point, mainly the implementation and upgrades portion, but I no longer have
a performance guy to lean on right now.
> > > >
> > > > Any thoughts?
> > > >
> > > > CJ Stringer
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
>