Discussion:
Change from V701 to V75 regarding queues
Pere Guerrero Olmedo
2013-07-23 12:00:22 UTC
Permalink
Hi

I've noticed in my new QMGR's installed with version V7.5 that queues are not directories with a file called "q" anymore.

Now they are files in the path /var/mqm/qmgrs/myqmgr/queues/

I didn't find anything in the V701 to V75 changes chapter.

The only thing is in the Table:
Table 1. Default content of a /var/mqm/qmgrs/qmname/ directory on UNIX systems
Is documented :
queues/ Each queue has a directory in here containing a single file called q

And in V7.5 in the table:
Table 2. Documented contents of the /var/mqm/qmgrs/qmname directory on UNIX systems
Is documented:
authinfo/ Each object defined within the queue manager is associated with a file in these directories.
channel/ The file name approximately matches the definition name; see, Understanding WebSphere MQ file names .
clntconn/
listener/
namelist/
procdef/
queues/
services/
topics/

Do you know if it only affects to new installations or in migration ones as well?

And due to disk performance, is it possible to have the "old" (V7.0.1) Unix directories structure?

Thanks
Regards.
Pere

________________________________

AVISO DE CONFIDENCIALIDAD.
Este correo y la información contenida o adjunta al mismo es privada y confidencial y va dirigida exclusivamente a su destinatario. everis informa a quien pueda haber recibido este correo por error que contiene información confidencial cuyo uso, copia, reproducción o distribución está expresamente prohibida. Si no es Vd. el destinatario del mismo y recibe este correo por error, le rogamos lo ponga en conocimiento del emisor y proceda a su eliminación sin copiarlo, imprimirlo o utilizarlo de ningún modo.

CONFIDENTIALITY WARNING.
This message and the information contained in or attached to it are private and confidential and intended exclusively for the addressee. everis informs to whom it may receive it in error that it contains privileged information and its use, copy, reproduction or distribution is prohibited. If you are not an intended recipient of this E-mail, please notify the sender, delete it and do not read, act upon, print, disclose, c
Andy Hickson
2013-07-23 14:54:18 UTC
Permalink
Pere,
This change was made to cope better with very large numbers of queues, where
in some cases we were hitting limits on the number of sub-directories that
could exist under the queues directory.
Can you explain why eliminating a level in the directory tree is causing you
a "disk performance" concern ?

Thanks
Andy.

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Bruce Lerner
2013-07-23 15:26:17 UTC
Permalink
Why do you attribute performance degradation due the lack of the 'q'
artifact in the filesystem?

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Pere Guerrero Olmedo
2013-07-24 08:21:09 UTC
Permalink
Hi Andy, good to see you.

From several white papers and lot of conferences, chats and so on, always we were advised to separate FS of logs and queues for performance / integrity purposes.

It seems reasonable to think that in QMGR with high volume of messaging in different queues, having separate FS per queue would help as well (when messages can not be delivered when they are in the buffers).

In fact I've assumed all the time, MQ guys created this model of 1 directory per queue in order to promote the fact of using different FS (similarly to Mainframe model with Pagesets).

To be honest, I don't have any evidence, that show me if there will be a significant difference between both scenarios, but don't have it about defining logs and queues in the same FS either.

For new installations, I assume this point, but for migrations it will cause me some headaches, so I have to redefine all the disk organization.

Due to this, at least I would recommend IBM to include in the migration manual a warning related to this (I really don't think, I'm the only one in the world who defines separate FS per critical queues... :-) )

Thanks for confirming in this post my suspicions.

Regards.
Pere


-----Mensaje original-----
De: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] En nombre de Andy Hickson
Enviado el: martes, 23 de julio de 2013 16:54
Para: ***@LISTSERV.MEDUNIWIEN.AC.AT
Asunto: Re: Change from V701 to V75 regarding queues

Pere,
This change was made to cope better with very large numbers of queues, where in some cases we were hitting limits on the number of sub-directories that could exist under the queues directory.
Can you explain why eliminating a level in the directory tree is causing you a "disk performance" concern ?

Thanks
Andy.

To unsubscribe, write to ***@LISTSERV.MEDUNIWIEN.AC.AT and, in the message body (not the subject), write: SIGNOFF MQSERIES Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

________________________________

AVISO DE CONFIDENCIALIDAD.
Este correo y la información contenida o adjunta al mismo es privada y confidencial y va dirigida exclusivamente a su destinatario. everis informa a quien pueda haber recibido este correo por error que contiene información confidencial cuyo uso, copia, reproducción o distribución está expresamente prohibida. Si no es Vd. el destinatario del mismo y recibe este correo por error, le rogamos lo ponga en conocimiento del emisor y proceda a su eliminación sin copiarlo, imprimirlo o utilizarlo de ningún modo.

CONFIDENTIALITY WARNING.
This message and the information contained in or attached to it are private and confidential and intended exclusively for the addressee. everis informs to whom it may receive it in error that it contains privileged information and its use, copy, reproduction or distribution is prohibited. If you are not an intended recipient of this E-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, ret
Loading...