Operating System - OpenVMS
1748017 Members
3829 Online
108757 Solutions
New Discussion юеВ

Re: About use of RAB$V_NQL No Query Locking

 
SOLVED
Go to solution
Hein van den Heuvel
Honored Contributor

Re: About use of RAB$V_NQL No Query Locking

>> The information that you put here are very valuable and clarify me many thinks about OpenVMS LOCKS

Good!

>> the real situation is that during the night run a lot of batch processes, many of then them only read the files sequentially to generate reports and files to send to another aplications outside Alpha plataforms

Ok, so maybe you want to try completely different approaches.

- Use (Host-Based) shadowing to detach a member with a clone of a file.

- Use BACKUP/IGNORE=INTERLOCK to take a readonly snapshot of the file. If you have the memory, then stick the copy into a RAMdisk for transfer + delete?

- my (customers) preferred solution is to use the commercial Vselect tool (EGH company, John Santos and friends) to take a sequential file extract, with or without selection criteria. Vselect can read indexed file faster than RMS can, and uses no locks.

- write your own, or commission someone to create, an extract tool. That's not too hard for specific cases, but more tricky for a solid, commercial solution. (Check out DIX)

- tune the file for bigger data bucket. The reduces ENQ/DEQ proportinally, exchanging them for cheaper Converts to/from NL.

>> and others processes modifying data on the same files, but it run slow I think could be by the high generated locks.

Or because the XFC cache does not get a chance to help?

>> I send a picture with the amount of locks during 24 hours and a MONITOR DLOCK from the GS1260 machine.

Good stuff, but I'd prefer to see more quantitative words around 'it run slow'.
Because that seems to be the real problem you are trying to solve and you have not convinced me yet that locks are the cause for that.

Cheers!
Hein.
Jose Antonio Rocha
Occasional Advisor

Re: About use of RAB$V_NQL No Query Locking

Hein

Thanks for your contribution, I only want that you review the attached information, where in my modest opinion the LOCK is the principal cause of the low performance. Could you tell me if agree with this conclusion?

Thanks a lot for your attention.

Jose
Hein van den Heuvel
Honored Contributor

Re: About use of RAB$V_NQL No Query Locking

>> Thanks for your contribution, I only want that you review the attached information, where in my modest opinion the LOCK is the principal cause of the low performance.

I don't 'see' any low performance.
What is the (end user) measurement for that?
Is the performance good for most of the day, but acceptable during the nightly (transfer?) jobs?

The system is busy and has High MPsync at the time to took the snapshots, but the full day picture shows a relatively healthy system during most of the day. Lots of usermode, little kernel/mpsync overhead... except around midnight.

I'd recommend switching to the dedicated lock manager to reduce overhead and turn the cpu locking MPsyncs into low priority kernel mode waits.

Given the amount of memory, I would certainly consider how you could deploy read-only file clones.

And if extracts and selects are seen as not fast enough, and critical for the end user perception / SLA's then I would looks at alternatives for that, such as the commercial tool mentioned.

At this point this topic start to become too much like 'work' for me, and you exceeded your 'first 15 minutes are free' quota from me. Maybe someone else will step up, or contact me offline.

Best regards,
Hein van den Heuvel ( at gmail dot com )
HvdH Performance Consulting



Jose Antonio Rocha
Occasional Advisor

Re: About use of RAB$V_NQL No Query Locking

Thanks a lot to all people who answers to this question, I will continue investigating about this issue at the customer site.

Regards

Jose
Hoff
Honored Contributor

Re: About use of RAB$V_NQL No Query Locking

> Given the amount of memory, I would certainly consider how you could deploy read-only file clones.

Cloning can be an option, as can be sharding the data. There are other approaches toward increasing performance and parallelism.

One of the general approaches here involves the DECset PCA or such tool, and determining where the application(s) are spending the most time. OpenVMS locking (particularly on recent OpenVMS versions) is pretty speedy. Excessive locking can point to some underlying application or file-level issue.

I've also seen the NQL knob used for an on-line archive; to work around some other application that's holding a lock for too long. For similar reasons around why BACKUP /IGNORE = INTERLOCK can produce questionable results, the use of NQL here can be problematic, too.
Hein van den Heuvel
Honored Contributor

Re: About use of RAB$V_NQL No Query Locking

I mentioned VSELECT from EGH as a commercial solution to extract indexed file records faster than RMS can, without locks.

Ther eis a freeware solution bin Fekko Stubbe called DIX.

The extract would roughly look like (good luck with the Dutch comments!):

$ DIX FILE/FAST file -
/DES=$LINE - !een descriptor met een veld char*nnnnnn
/OUTPUT=x.x -
/WIDTH=nn - !groot genoeg om het record te bevatten, ander gaat dix wrappen
/DISPLAY=(NOALL,DATA) - !alleen de data, niet de offset/veldnaam
/FORMAT=PASSALL - !Unprintables zo laten als het is (anders worden het .tjes)
zoekterm [zoekterm]

zoekterm = RSE = Record selection expression. Tons of options. See HELP.

http://www.oooovms.dyndns.org/dix/

Hein.