Ansicht
Dokumentation
12556 - MTXW Status and Job QGYSERVER
CL_GUI_FRONTEND_SERVICES - Frontend Services General Data in Customer MasterThis documentation is copyright by SAP AG.
MTXW Status and Job QGYSERVER
Hi Victor,you can't configure anything at the DB-Mon ...
Either you turn it on or you turn it off.
MTXW:
> DBMON_HDR1
> DBMON_DATA01
> DBMON_DATA04
> DB_TBUFF
The first 3 are from the DB-Mon, the last one is a reorg stuff of
the SAP table buffer.
From the figures, you are telling, the hardware seems to be "useful
loaded" but not totally at the end - at least not if the 80% is not
very long over the day. More deeper results can only be done on an
individual base.
Keep in mind, that you have to update your PTFs on a very regular
base in order to participate from all improvements.
Regards
Volker
--- In DoNotReply@consolut.eu, vlinZp... wrote:
> Hello Volker,
>
> I found some SQL 913 errors on table D010SINF in ST22 from
workflow-
> related program and I will open an OSS message later.
>
> I forgot to mention the timing of the MTXW statues. It last from
one
> to five seconds most of the times (based on the experience of my
> clicking F10 key when WRKACTJOB SBS(R3_xx)). Sometimes it could be
> as long as 10 seconds or more for some work processes (not all of
> them). We saw all the dialog work processes are running in Tcode
> SM50 a few times last week and suspected that it was related to
some
> kind of locking issue. But so far we have not found directly link
of
> it to MATX status.
>
> After using a F5 macro, I caught the following objects in mutexes
> monitor:
>
> DBMON_HDR1
> DBMON_DATA01
> DBMON_DATA04
> DB_TBUFF
>
> They look related to DB monitor. (It might be normal because they
> didn't stay long when the F5 macro was running.)
>
> Can we verify that our DB monitor (also performance monitor?) is
> configed correctly to give enough info to ST04 and have minimal
> overhead? I checked the redbook again and didn't find the
suggested
> config of it.
>
> In the business hours, we have CPU usage 50% - 80%, DB capability
15-
> 20%, 0 for Wait-Inel and Act-Inel, about 50 DB faults and 300 Non-
DB
> faults in 19G *BASE pool from WRKSYSSTS and disks about 5%-8% busy
> from WRKDSKSTS. Do you think we are close to limit of the
hardware?
> (Based on a false assumtion that we are updated to everything and
> have fine tuned the ABAP programs.) If yes, should we say that CPU
> is the bottleneck?
>
> Thank you very much,
> Victor
>
>
> --- In DoNotReply@consolut.eu, "Volker Gueldenpfennig"
> <volker.gueldenpfennigZs...> wrote:
> > Hi Victor,
> >
> > MTXW has to be analyzed for the root cause. Try WRKACTJOB 5 and
> then
> > 19. Then you should make a hardcopy and open an OSS ticket with
> that.
> > If it is QQQDBMTR, it is caused because of the DB-Mon. Otherwise
> it
> > will be caused because of SAP somehow. We would have to
> investigate.
> > QGYSERVER really looks like SQL0913 ...
> >
> > But, the SQL0913 could be caused because of the long MTXWs in
> other
> > WPs. Often this is happening together.
> >
> > Regards
> >
> > Volker
> >
> > --- In DoNotReply@consolut.eu, "Lin, Victor" <vlinZp...>
> wrote:
> > > Hello everyone,
> > >
> > > After we upgraded OS/400 from V4R5 to V5R2 with CumPack 3252,
DB
> > Fix 10, and other individual PTFs and upgraded SAP kernel to
1617,
> > we noticed that the dialog work processes are in MTXW status
more
> > frequently than ever. From F1 help (The initial thread of the
job
> is
> > in a mutex wait. A mutex is a synchronization function that is
> used
> > to allow multiple jobs or processes to serialize their access to
> > shared data.) it looks like a locking wait. But why?
> > >
> > > Also we are getting jobs QGYSERVER under the subsystem R3_XX.
We
> > used to get those jobs when we are applying the support packages
> > with user activities on the system, and they went away days
after
> > the support packages were finished. But now (10 days after the
> last
> > time we applied the support packages) there are still about 20
> > QGYSERVER jobs in DEQW status which entered the system about 1
or
> 2
> > hours after midnight in the last a few days.
> > >
> > > Meanwhile we found and fixed a few slow transactions like
MB52.
> > But more transactions, for instance V/LD, VK34, and MM17, shows
> > performance issues. Does anyone have similar experiences with
them?
> > >
> > > Any help or hint is appreciated!
> > >
> > > Thank you very much,
> > > Victor
> > > SAP Basis Manager
> > > Plastipak Packaging INC
Durban Tours - Südafrika Safari
PERFORM Short Reference SUBST_MERGE_LIST - merge external lists to one complete list with #if... logic for R3up
This documentation is copyright by SAP AG.
Length: 6033 Date: 20240419 Time: 105154 sap01-206 ( 5 ms )
