From nobody Thu Apr 06 22:41:18 2023 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4PsxLk1Mcsz43Tsx for ; Thu, 6 Apr 2023 22:41:34 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-ua1-f51.google.com (mail-ua1-f51.google.com [209.85.222.51]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PsxLh6tllz4LN4 for ; Thu, 6 Apr 2023 22:41:32 +0000 (UTC) (envelope-from asomers@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of asomers@gmail.com designates 209.85.222.51 as permitted sender) smtp.mailfrom=asomers@gmail.com; dmarc=none Received: by mail-ua1-f51.google.com with SMTP id 89so28879597uao.0 for ; Thu, 06 Apr 2023 15:41:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680820890; x=1683412890; h=content-transfer-encoding:cc:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=tPd4nBLJo2O35VpR3bq8hwaZ1H+K62dHu+YqTIKfQJA=; b=0unls5Q1B9d+Z1lCi0b6SOLVw0g9ywOLtnKDveIppTMq3f8Nv6/70gczNYUWNCdokQ /pxwpWJlc0KnfSOTpQZo0WLgIp4VK61COysvEYEOyK2zl7s/jC6hP3LIhrO1ERGABj7t CIlyDMncvHgseP2E0kxeeph4KYC1/IbHxqrKlFd9ZKliq34aUlR5gHdFiD28FjndY+f2 ZK1gq1DFL2IXNyA4cYVuTmtc1klUkt4qOlWnXBQyNMvjWUrzUGL7Dk8dEiFw2Iu+v05k kxyqHwK6ZiBTvuwM9tpqycS0ifBisEXlLjevyaBBLRk3+Z+ySnguGKy3YaPCr4XuY87t kDzw== X-Gm-Message-State: AAQBX9eYkL9LwoekSckj64HQNsmrj4cVn17OB6k5sY/N3if0jVO09Cgb Fo1p+UTvoT5agHQFRk/C/1Bt/QoeWtzaysBjNbLzPERgAqU= X-Google-Smtp-Source: AKy350aEOtfwhNapGAiDxs7aRrf42B/8OoXIKGYq8Hr1hAo+bmPHLchmX5z4T5g15zSllPm0+7pc796e+KUQgNVjN8w= X-Received: by 2002:ab0:5491:0:b0:73f:f15b:d9e3 with SMTP id p17-20020ab05491000000b0073ff15bd9e3mr68771uaa.0.1680820890443; Thu, 06 Apr 2023 15:41:30 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Alan Somers Date: Thu, 6 Apr 2023 15:41:18 -0700 Message-ID: Subject: Re: textdumps are too slow Cc: FreeBSD CURRENT Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Result: default: False [-1.00 / 15.00]; MISSING_TO(2.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[209.85.222.51:from]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; DMARC_NA(0.00)[freebsd.org]; FROM_HAS_DN(0.00)[]; ARC_NA(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.222.51:from]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; TO_DN_ALL(0.00)[]; FREEFALL_USER(0.00)[asomers]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FREEMAIL_ENVFROM(0.00)[gmail.com]; R_DKIM_NA(0.00)[]; FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com]; TO_DOM_EQ_FROM_DOM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4PsxLh6tllz4LN4 X-Spamd-Bar: / X-ThisMailContainsUnwantedMimeParts: N On Thu, Apr 6, 2023 at 9:08=E2=80=AFAM Alan Somers wr= ote: > > I have servers with lots of RAM yet slow swap disks. So full crash > dumps are too slow. Instead, I use textdumps, which are theoretically > much faster. However, these servers also have about 10,000 threads > apiece, so textdumps are also slow. They take tens of minutes. I > have dual console setup: both serial and video. It seems to me that > the speed of the textdump might be limited by the video system. So is > there anyway to capture a textdump without printing everything to the > console? textdump(4) implies that there isn't; you must print stuff > to console in order to capture it, and you must capture in order to > dump. Would somebody please tell me that I'm wrong? > > -Alan I'll answer my own question. It turns out that ddb can mute the console, just like "conscontrol mute on" would. That makes textdumps much much faster. The command is "write cn_mute 1". So to use this trick, write the following to /etc/ddb.conf: script kdb.enter.panic=3Dtextdump set; capture on; write cn_mute 1; run lockinfo; show pcpu; bt; ps; alltrace; capture off; textdump dump; reset