I'm relatively new to GT.M, and I don't see this discussed in the administrator's guide.
The default block size is 1 KB. On Linux, the page size is 4 KB:
# getconf PAGESIZE
In the general case, it seems that the optimal block size would be a multiple of the page size.
In I/O limited applications, you are correct - the optimal block size for x86 GNU/Linux would be a multiple of 4K. For CPU bound applications, a smaller block size may give better performance. In general, smaller block sizes are more CPU efficient and larger block sizes (multiples of the "natural" I/O block size) are more I/O efficient. So there is no universally correct answer.
The defaults are intended for out-of-the-box playing with GT.M, rather than being suitable for production.
Hi baskar and others all
the max zbitstr is about 250,000
it about 32k I checked in $L
this cause an error on ^GLOB settings of record-size error , that is about 4k
what I have to do ?
to increase the blocksize,recordsize to about 32,000 ?
otherwise the zbitstr will not work
In GT.M, a global variable must fit within a database block. In the GT.M V5 database format, each block has an overhead of 16 bytes, so the global variable node, including variable name and subscripts, must fit within the block.
Remember that database block sizes are immutable once a database file is created. Therefore, you will need to define a bigger block size in the global directory file that mupip create will use to create a new database file with a sufficiently large block size.
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.