optimal block size?

  • Jon Willeke

    Jon Willeke - 2002-06-21

    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.

    • K.S. Bhaskar

      K.S. Bhaskar - 2002-06-21

      Jon --

      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.

      -- Bhaskar

      • ell

        ell - 2008-03-05

        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

        • K.S. Bhaskar

          K.S. Bhaskar - 2008-03-05

          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.

          -- Bhaskar


Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks