Posts by emert

Hi Marcel,

thanks for your reply. Concerning the lua line I mistyped, sorry, it is actually
[lua]
print('--->' .. heapinfo())
but still does not show any output. Do I have to add anything? Below I attached my full dicom.ini.

Conquest and mysql are the only applications running on my server. The statistics from iostat show wBlk_srv/s : 200-300 which corresponds to 2-3 DB writes/sec.
In serverstatus.log I see for every image the line
[recompress]: recompressed with mode = un (strip=0)
I actually thought with mode un there is no compression?!

Kind regards
Frank

dicom.ini:
# This file contains configuration information for the DICOM server
# Example Linux version using MySQL
# Copy this file to dicom.ini to use it

[sscscp]
MicroPACS = sscscp
Edition = Personal

# Network configuration: server name and TCP/IP port#
MyACRNema = CONQUESTSRV1
TCPPort = 5678

# Reference to other files: known dicom servers; database layout; sops
ACRNemaMap = acrnema.map
kFactorFile = dicom.sql
SOPClassList = dgatesop.lst

# Host for postgres or mysql only, name, username and password for database
SQLHost = localhost
SQLServer = conquest
Username = conquest
Password = ***
PostGres = 0
MySQL = 1
SQLite = 0

UseEscapeStringConstants = 0
DoubleBackSlashToDB = 1
#IndexDBF = 1
#PackDBF = 0
#LongQueryDBF = 1000

# Configure database
TruncateFieldNames = 10
MaxFieldLength = 254
MaxFileNameLength = 255
FixPhilips = 0
FixKodak = 0
UIDPrefix = 99999.99999
EnableReadAheadThread = 1
PatientQuerySortOrder =
StudyQuerySortOrder =
SeriesQuerySortOrder =
ImageQuerySortOrder =
EnableComputedFields = 0
TCPIPTimeOut = 300
FailHoldOff = 60
RetryDelay = 100
QueueSize = 128
WorkListMode = 0
WorkListReturnsISO_IR_100 = 1
DebugLevel = 4
Prefetcher = 0
LRUSort =
AllowTruncate =
DecompressNon16BitsJpeg = 1
UseBuiltInJPEG = 1
IgnoreOutOfMemoryErrors = 1
PadAEWithZeros = 0
FileNameSyntax = %modality/%id/Study_%studyid/Series_%seriesid/%sopuid.dcm

# Configuration of compression for incoming images and archival
DroppedFileCompression = un
IncomingCompression = un
ArchiveCompression = as

# Names of the database tables
PatientTableName = DICOMPatients
StudyTableName = DICOMStudies
SeriesTableName = DICOMSeries
ImageTableName = DICOMImages
DMarkTableName = DICOMAccessUpdates
RegisteredMOPDeviceTable = RegisteredMOPIDs
UIDToMOPIDTable = UIDToMOPID
UIDToCDRIDTable = UIDToCDRID

# Banner and host for debug information
PACSName = CONQUESTSRV1
OperatorConsole = 127.0.0.1

# Configuration of disk(s) to store images
MAGDeviceThreshhold = 0
MAGDevices = 1
MAGDevice0 = /pacs/pacs

[lua]
endassociation = print('--->' .. heapinfo())

Hi Marcel,

a few weeks ago I migrated our Linux Conquest from v1.4.14 (32 bit) to 1.4.16 on a new server (64bit, 4GB RAM).

Since then I observe a constant increase in memory usage from around 300MB (after reboot) to 4GB (after 2 days) with a significant performance decrease (especially write operations). I checked several forum posts and added
[lua]
endassociation = (print('--->' .. heapinfo())
to dicom.ini to get some memory info, but is does not show any output (I'm not familiar with lua).

Since I assume it is a problem related to memory leakage my questions are
1. How can I log the relevant information correctly?
2. Is this a known problem?
3. How can I overcome the problem (migration to 1.4.17)?

Thanks in advance for your feedback.

Kind regards
Frank

Hi Marcel,

I'm going to upgrade Conquest running under Linux from 1.4.14 (on 32bit; old server) to 1.4.16 (64bit) on a new server.

For the migration I have one question: Can I simply run clonedb (under 1.4.16) to migrate the DICOM tables under 1.4.14 to 1.4.16 (I saw that the table structure changed) or do I have to regenerate the new DB from a DICOM file level in order to create it properly (takes obviously much longer)?

Thanks for your feedback.

Kind regards
Frank

Hello,
due to performance problems with our overall PACS (Conquest as server on Linux) that could have various reasons (hardware, network, etc.) I started an applicatory performance analysis monitoring the Conquest accesses based on a perl script parsing the daily log files. Thereby I figured out that the Conquest log mechanism running in multi-threaded mode mixes the log entries belonging to various threads which limits the approach only to single-threaded mode.
Obviously this operation mode increases our performance problems.
A possible solution would be to add the current thread number to each line logged (not only to start and end of the thread) so that a simple sort before parsing the daily log files would overcome this problem.
Have you already thought of such a feature or is something planned for the next release?
Thank you in advance.
Best regards,
Frank Emert