Skip to content

View Memory and Cache Usage in Developer Mode

  • Version: 1.0.7-7-g251eead
  • Release Date: 2023-04-06 11:17:57
  • Supported OS: windows/amd64, windows/386, linux/arm, linux/arm64, linux/386, linux/amd64

Description

During development, testing, or actual runtime, the cache size generated by Lua can sometimes be uncontrollable. For example, caching the file list of a directory may consume too much memory when the number of files is large, potentially triggering cgroup limits and causing the process to hang or freeze.

Therefore, it is necessary to use Developer Mode to monitor memory and cache usage in real time during runtime.

cache_dev Developer Mode

Problems to solve and approaches:

  • Memory or CPU fluctuates significantly, but the root cause cannot be located.
  • To solve the problem of excessive cache usage, it is necessary to know how much data is cached.
  • During caching, the cache type is only known when storing or retrieving (within the same Lua script or script with the same functionality).
  • However, the cache unit does not know the specific storage type.
  • Sizes can be determined for string, bool, and int/float types, but the size of lua.table structure types cannot be directly obtained.
  • Therefore, lua.table types should be handled differently, such as being persisted to disk.
  • This ensures that scheck does not consume too much memory during runtime (it should not occupy more than 150 MB).
  • If scheck terminates abnormally, it should be able to resume execution from the state before termination (like a breakpoint restart).

Solution:

  • Caches used by the same script type are identical, but different files (different rule IDs) may store two identical copies of the same key. Therefore, the same cache should be used instead of storing two separate copies.
  • Solving the previous problem introduces another issue: all rules have their own cache keys, which can easily cause confusion.
  • Cache persistence and visualization. The benefits include rapid problem localization, mock testing, and rule testing.
  • After persistence, memory overhead can be correspondingly reduced.

Configuration

Open the configuration file and set pprof to true.

[system]
    ...
 pprof = true

After enabling this switch, the local port 127.0.0.1:6060 will be listened on, accessible only from the local machine. Use the go pprof command to view memory and CPU usage. Official documentation

# Then use the pprof tool to view the heap profile:
go tool pprof http://localhost:6060/debug/pprof/heap
# top 20 
top 20
# list func name or pkg name 
list

# Or view a 30-second CPU profile
go tool pprof http://localhost:6060/debug/pprof/profile
# Or view the Go routine blocking profile
go tool pprof http://localhost:6060/debug/pprof/block

# To see all available profiles, visit http://localhost:6060/debug/pprof/ in your browser. To learn how these facilities work, visit
http://blog.golang.org/2011/06/profiling-go-programs.html

Cache

After enabling Developer Mode, cache generated by Lua scripts will be serialized to cache.json in the installation directory.

Currently supported Lua cache types: LTString, LTNumber, LTBool, LTTable.

Unsupported Lua types: LTChannel, LTFunction, LTNil, LTThread, LTUserData.

{
    "msg_data": {
        "/boot/grub2/grub.cfg": {           // key
            "c_type": 0,
            "rule_name": "0070-grub-priv", // rule name
            "val": "-rw-r--r--"             // val string type
        },
        "/etc/fstab": {
            "c_type": 1,
            "rule_name": "0029-fstab-exist",
            "val": true             // val bool type
        },
        "/usr/lib/systemd/system/docker.socket": {
                "c_type": 2,
                "rule_name": "0307-docker-socket-priv",
                "val": 420          // val number type
        }
    ... 
  }
}

All cache data is written to the file at regular intervals. scheck does not read the cache content. Features such as breakpoint restart will be implemented in future releases.

Feedback

Is this page helpful?