Uploaded image for project: 'MongoDB ETL Tools'
  1. MongoDB ETL Tools
  2. TOOLS-600

mongostat column alignment is not steady

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Fixed
    • Affects Version/s: 3.0.0-rc6
    • Fix Version/s: 3.0.0-rc7
    • Component/s: mongostat
    • Labels:
      None
    • Environment:
      Linux x64

      Description

      It seems there was a change in the way column alignment is performed such that columns tend to become more severely misaligned.

      Below is an example where particularly after resident mem the columns expand and contract greatly, making the output more difficult to follow.

          *0  3768   1988     *0     112   662|0     3.6    7.1       0  9.8G 5.5G 306|162 398|222    2m    11m 3732 mmsconfig1  PRI 02:34:53
           4  3670   1850     *0      60   643|0     3.7    7.2       0  9.8G 5.5G 131|83 335|227    1m    11m 3734 mmsconfig1  PRI 02:34:58
          *0  3415   1906     *0      46   609|0     3.8    7.2       0  9.8G 5.5G 357|183 374|185    1m     9m 3734 mmsconfig1  PRI 02:35:03
           2  3780   1868     *0      72   597|0     3.9    7.2       0  9.8G 5.5G 190|136 260|170    2m    10m 3735 mmsconfig1  PRI 02:35:08
           3  3457   1906     *0      44   584|0     4.0    7.2       0  9.8G 5.6G 128|72 245|140    1m     9m 3739 mmsconfig1  PRI 02:35:13
      insert query update delete getmore command % dirty % used flushes vsize  res qr|qw   ar|aw netIn netOut conn        set repl     time
          *0  3496   1387     *0      33   653|0     4.0    7.2       0  9.8G 5.6G 84|17 586|232    1m    10m 3763 mmsconfig1  PRI 02:35:18
          *0  3623   1630     *0      40   612|0     4.1    7.2       0 10.0G 5.6G 52|25 579|233    1m    11m 3846 mmsconfig1  PRI 02:35:23
           4  3864   1794     *0      82   618|0     0.7    7.2       1 10.1G 5.7G 123|61 384|214    1m    12m 3914 mmsconfig1  PRI 02:35:28
           1  3427   1961     *0      82   598|0     2.0    7.3       0 10.2G 5.7G 90|55 242|169    2m    10m 3918 mmsconfig1  PRI 02:35:33
           2  3314   1708     *0      59   554|0     2.5    7.3       0 10.2G 5.7G 55|32 246|158    1m    10m 3919 mmsconfig1  PRI 02:35:38
           3  3336   1701     *0      59   590|0     2.9    7.3       0 10.2G 5.8G 154|87 272|172    1m    10m 3919 mmsconfig1  PRI 02:35:43
           1  3308   1768     *0      98   647|0     3.2    7.3       0 10.2G 5.8G 159|76 265|149    1m    10m 3920 mmsconfig1  PRI 02:35:49
           2  3360   1696     *0      62   621|0     3.5    7.3       0 10.2G 5.8G 51|35 297|161    1m     9m 3920 mmsconfig1  PRI 02:35:54
           6  3507   1754     *0      44   606|0     3.6    7.4       0 10.2G 5.8G 344|116 388|237    1m     9m 3920 mmsconfig1  PRI 02:35:59
           1  3486   1856     *0      70   595|0     3.8    7.4       0 10.2G 5.8G 41|34 360|260    2m    10m 3922 mmsconfig1  PRI 02:36:04
      insert query update delete getmore command % dirty % used flushes vsize  res   qr|qw   ar|aw netIn netOut conn        set repl     time
           3  3319   1839     *0      56   585|0     3.9    7.4       0 10.3G 5.8G 211|140 307|249    1m    10m 3938 mmsconfig1  PRI 02:36:09
           3  3102   1687     *0      53   613|0     4.0    7.4       0 10.3G 5.8G 28|62 476|353    1m     9m 3963 mmsconfig1  PRI 02:36:14
           1  3520   1666     *0      42   547|0     4.1    7.4       0 10.3G 5.9G 381|166 401|182    1m     9m 3963 mmsconfig1  PRI 02:36:19
           1  3682   1515     *0      59   603|0     4.2    7.4       0 10.4G 5.9G 364|181 430|224    1m    10m 3963 mmsconfig1  PRI 02:36:24
           4  3519   1650     *0      63   632|0     4.0    7.4       1 10.4G 5.9G 357|184 487|238    1m    10m 3963 mmsconfig1  PRI 02:36:29

      Off the top of my head I believe the behavior used to be to continue expanding right as needed but never contracting back left. So at worst the width expands to fit the widest ever observed such that from then on the alignment's always exact, even if values later "contract" from their max width.

        Attachments

          Activity

            People

            • Assignee:
              adinoyi.omuya Adinoyi Omuya
              Reporter:
              john.morales John Morales
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: