It is possible for a tserver's memory consumption to exceed --memory_limit_hard_bytes if the tserver is hosting an excessive amount of tablets (or tablet data blocks). That's usually a sign that the tserver is overloaded relative to the amount of resources allocated to it by the operator, and should either shed load (i.e. tablets), or should be given more memory. Put another way, there's overhead associated with each hosted tablet that must be accounted for in the memory limit; this overhead is usually small unless the tserver is in excess of Kudu's scale limits (https://kudu.apache.org/docs/known_issues.html#_scale).
In any case, I don't see how this can lead to a machine crash. The Linux out-of-memory (oom) killer will kill a memory intensive process when the system is under too much memory pressure, and Kudu is no exception. Could you provide more information on this specific case? What is the configured value of --memory_limit_hard_bytes? How many tablets is the failing tserver hosting? How much data is on the node? Sharing the tserver log (beginning with its startup) would help here. On Tue, Oct 30, 2018 at 8:15 AM [email protected] <[email protected]> wrote: > > Hi： > I used Kudu version 1.4.0（1 master , 3 tserver）, and there is a > problem : tserver can't be started, the process will run out of operating > system memory, resulting in the use of swap partitions, resulting in high CPU > load and machine crash. The --memory_limit_hard_bytes flag does not take > effect. > > > ________________________________ > [email protected]
