Embarrasing; however after an iterative process of resolving what appeared to be the most significant issue in each iteration, the root cause of my issue was not enough swap space. Where IBM suggests 25%-50% of physical memory, Red Hat suggests 2 times the physical memory when physical memory is less than 2 GB.
On my small 1x1, now with a 2GB swap partition, a db2sampl completes in ~92 seconds:
[root ~]# lsblk | grep xvdb
xvdb 202:16 0 2G 0 disk [SWAP]
└─xvdb1 202:17 0 2G 0 part
[root ~]#
[db2inst1 20250422]$ date ; db2sampl -dbpath /db2files/data/SAMPLE -name SAMPLE ; date
Tue Apr 22 03:26:10 PM UTC 2025
Creating database "SAMPLE" on path "/db2files/data/SAMPLE"...
Connecting to database "SAMPLE"...
Creating tables and data in schema "DB2INST1"...
Creating tables with XML columns and XML data in schema "DB2INST1"...
'db2sampl' processing complete.
Tue Apr 22 03:27:42 PM UTC 2025
[db2inst1 20250422]$
------------------------------
Paul J Pearon Jr DB2 DBA
Columbus
+1 614-561-3225
------------------------------
Original Message:
Sent: Tue April 22, 2025 04:24 AM
From: Mark Barinstein
Subject: DB2 v12.1.1.0 in docker: DIA8558C A message queue did not exist.
I was patient enough to take traces with db2trc during a simpliest 'CREATE DATABASE TEST' on both docker and non-docker environments.
It took 5432 sec (!) on docker and 465 sec on non-docker.
I've attached performance reports of both traces.
10 rows from both here:
docker:
nCalls TotalElapsed AvgElapsed TotalSpent AvgSpent FunctionName
174522 49653.823299000 0.284513261 49653.812878000 0.284513201 sqloWaitEDUWaitPost
9465 28526.753046000 3.013920026 28526.340919000 3.013876484 sqlorqueInternal
146 21581.114347000 147.815851692 21581.114347000 147.815851692 sqloCSemP
10411 16153.412636000 1.551571668 16153.412636000 1.551571668 sqloSSemP
17125 10898.872314000 0.636430500 10898.863693000 0.636429997 sqlorest
42884 8159.585756000 0.190271098 8159.585746000 0.190271098 sqloseekwrite64
4 5406.168140000 1351.542035000 5403.934969000 1350.983742250 sqpLoggpEdu::sqlpLoggpMain
29 5225.051637000 180.174194379 5225.051637000 180.174194379 sqloWaitIPCWaitPost
2912557 4966.958149000 0.001705360 4965.653906000 0.001704912 sqloLioAIOCollect
7 4200.001132000 600.000161714 4200.001132000 600.000161714 sqloAppWaitOnSync
non-docker:
nCalls TotalElapsed AvgElapsed TotalSpent AvgSpent FunctionName
21723 5322.396906000 0.245012057 5322.393474000 0.245011899 sqloWaitEDUWaitPost
162 3681.618037000 22.726037265 3681.618037000 22.726037265 sqloCSemP
496 1853.303741000 3.736499478 1853.235504000 3.736361903 sqlorqueInternal
963 1370.954436000 1.423628698 1370.954436000 1.423628698 sqloSSemP
3150 931.509255000 0.295717224 931.509200000 0.295717206 sqlorest
4 463.335327000 115.833831750 463.043596000 115.760899000 sqpLoggpEdu::sqlpLoggpMain
3 359.230246000 119.743415333 359.230246000 119.743415333 OSSHIPCSemaphore::wait
1 180.171867000 180.171867000 180.171867000 180.171867000 sqloWaitIPCWaitPost
36875 70.643512000 0.001915756 70.643512000 0.001915756 sqloseekwrite64
3090829 32.156275000 0.000010404 27.786466000 0.000008990 sqlbfix
------------------------------
Mark Barinstein
Original Message:
Sent: Sun April 20, 2025 10:32 AM
From: Paul J Pearon Jr
Subject: DB2 v12.1.1.0 in docker: DIA8558C A message queue did not exist.
I am experiencing the same messages and a similar hang on the current AWS RedHat 9.5 image. It is difficult to diagnose as most hang tools also appear to hang and produce no output.
I have not had the patience to wait more than 1 hour as a simple iostat capture also hangs within the first minute of issuing the create database. It is on a small VM (1 core, 1 GB RAM), but I will test another attempt and wait for a longer time. If it still appears to hang after a long time, I will test on a 4x16 VM before investing in more diagnostics.
Here is the start:
[db2inst1]$ date ; db2 create database sample on /db2data/SAMPLE ; date
Sun Apr 20 01:32:30 PM UTC 2025
------------------------------
Paul J Pearon DB2 DBA
Columbus
+1 614-561-3225
Original Message:
Sent: Fri March 07, 2025 12:07 PM
From: Mark Barinstein
Subject: DB2 v12.1.1.0 in docker: DIA8558C A message queue did not exist.
It's interesting, but a database creation doesn't really hang.
It takes ~ 1 HOUR to create an empty database or a SAMPLE database with db2sampl...
------------------------------
Mark Barinstein
Original Message:
Sent: Fri March 07, 2025 05:13 AM
From: Mark Barinstein
Subject: DB2 v12.1.1.0 in docker: DIA8558C A message queue did not exist.
Hello,
Tested on CentOS Stream 8, Ubuntu 22.04.
Behavior is the same.
https://www.ibm.com/docs/en/db2/12.1?topic=system-linux
I follow the instructions described at the link above.
[db2inst1@db2server ~]$ db2level
DB21085I This instance or install (instance name, where applicable:
"db2inst1") uses "64" bits and DB2 code release "SQL12011" with level
identifier "02020110".
Informational tokens are "DB2 v12.1.1.0", "s2412161033", "DYN2412161033AMD64",
and Fix Pack "0".
Product is installed at "/opt/ibm/db2/V12.1".
I see a number of messages like below in the db2diag.log file even I configure a container not to create any databases at startup.
2025-03-07-09.45.48.280784+000 I54008E634 LEVEL: Error
PID : 18018 TID : 139946528298880 PROC : db2
INSTANCE: db2inst1 NODE : 000
HOSTNAME: db2server
FUNCTION: DB2 UDB, oper system services, sqloOpenMLNQue, probe:1259
MESSAGE : ZRC=0x870F0042=-2029060030=SQLO_QUE_NOT_EXIST "Queue does not exist"
DIA8558C A message queue did not exist.
DATA #1 : Codepath, 8 bytes
9
DATA #2 : String, 16 bytes
R1100018018A1000
DATA #3 : signed integer, 4 bytes
2
DATA #4 : Database Partition Number, PD_TYPE_NODE, 2 bytes
0
DATA #5 : unsigned integer, 2 bytes
0
DATA #6 : signed integer, 4 bytes
2
A simple "db2 create db test" hangs with a number of the same messages.
The same is if I configure a container, say, to create a database with the `DBNAME` or `TO_CREATE_SAMPLEDB` env variables.
------------------------------
Mark Barinstein
------------------------------