From owner-freebsd-hackers@freebsd.org Fri Apr 20 19:17:43 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 817C8F948FF for ; Fri, 20 Apr 2018 19:17:43 +0000 (UTC) (envelope-from sblachmann@gmail.com) Received: from mail-ot0-x22b.google.com (mail-ot0-x22b.google.com [IPv6:2607:f8b0:4003:c0f::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 11B4183D90 for ; Fri, 20 Apr 2018 19:17:43 +0000 (UTC) (envelope-from sblachmann@gmail.com) Received: by mail-ot0-x22b.google.com with SMTP id l22-v6so244680otj.0 for ; Fri, 20 Apr 2018 12:17:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=TgCroV6fI22PpZ+wJKLBJrO98ckiJ4ECraDBlaKtCRs=; b=k1452kwPF9y4w3QFObcxBQHESxcOhBuXumpRW357dR+U835N+ForZ9XgeqYWgq2iCx 79MaKM6027+kJznQF7YQfHegKUl/IJyDPggwHRfQc5OVqsqL+DPWecYIGIDpzLsabE0u ulBILj6qvx5rChn8YeqMMv02j+A3NgWPKKO/J7CSaB1uFH1W57Z1pBpplvHVtwCP7JXu GNteYvDo6TxNloyLU0UiFvuWeG22vroa3t49cp2S9doRfZJDku3apqMex+GfUIi+nV4x YMG2u4/z8qIXvmvDkhqbzvFqNU0PmLm4NFL4Z0sdPx57boUiH7SyaUBR96alAA5nTkSt Xbow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=TgCroV6fI22PpZ+wJKLBJrO98ckiJ4ECraDBlaKtCRs=; b=fNVIx+iN3nrbMfPzPpoUlpWyogZZ9X8OQU44hIIMFoXUNzQrmGkCKqADRttvkXYDkp 7gGDkwXsE6k9EJem3RmKDWQ4EURqPkwtLkJX5utMeONKT47zQgI6YfMd/2YTqKn9jgCy PIC97ZwsfJs38Znus6PkacEWwD3ZKk59rEnqCx42PFxAC8wACUQ4OOSdi6KdPiELsEbF yeva59Jf/cDDEyYTMhQ7FmrmsehAc4bW9tDpObls/ko0OmkCqvKJpK1QCKtYp5TuVmQW W/RisHt9HgpdsaCIm6+Gbr5jq49kUPTbbJWfI+YIKAw1uzR4F9HcCs+iKBbtaW9laxdn ZSuQ== X-Gm-Message-State: ALQs6tAuT7PmlkVxhapThSq3HRuWYoOhHYxkD7SnkbbKGIOKeA1tx4BW sg2Nxtp8Ig390ur0IGI3i5PeaPU9iS3zXCsK2mI= X-Google-Smtp-Source: AB8JxZodV8vPg2Khb7XlCgHaSe8sHmVmgsPMseNpYnKedcl6OAz7x3n55ZL1mi/cCtVMvPqSk7lWJk5PqYJEWNuYGqY= X-Received: by 2002:a9d:4a90:: with SMTP id i16-v6mr3429028otf.294.1524251862526; Fri, 20 Apr 2018 12:17:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.201.60.135 with HTTP; Fri, 20 Apr 2018 12:17:41 -0700 (PDT) In-Reply-To: References: From: Stefan Blachmann Date: Fri, 20 Apr 2018 21:17:41 +0200 Message-ID: Subject: Re: Runaway processes freeze the system To: Yuri Cc: Freebsd hackers list Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2018 19:17:43 -0000 Ideally rctl(8) should be the solution. Actions can be defined to refuse to allocate more memory or kill processes that demand too much memory. By turning off swap and restricting memory usage one can improve performance by preventing the swapper making the system sluggish. However, rctl is only of limited use for desktop users, as Xorg fails to start if vmemoryuse gets restricted (no matter how big the value). So rctl(8) appears of practical use only for example for protecting servers and embedded systems from crashing and damaging filesystems because of user programs eating up too much memory. I advise you to experiment with it, as the rctl(8) documentation/man page seems partly incorrect/misleading, for example regarding per-user resource limiting. On 4/20/18, Yuri wrote: > I am getting this problem again and again: when some process allocates > too much memory the system to freezes. > > My memory size is 24GB, and swap is only 4GB. I know that increasing the > swap size should reduce the chance of this happening, but it obviously > can't eliminate the problem. > > > What is the expected behavior of the system in such situation? To me it > looks like it is wait-and-see, and this causes this problem. > > A better strategy would be to maybe wait for some time, but if when the > problem persists to kill the largest, the most active, or the offending > process. > > > 11.1 amd64 > > > Yuri > > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" >