From nobody Tue May 13 14:43:07 2025 X-Original-To: freebsd-cloud@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 4ZxfNV32JDz5vRm6 for ; Tue, 13 May 2025 14:43:22 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from mail.nomadlogic.org (mail.nomadlogic.org [66.165.241.226]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4ZxfNT1Tlsz3gjj for ; Tue, 13 May 2025 14:43:21 +0000 (UTC) (envelope-from pete@nomadlogic.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=nomadlogic.org header.s=04242021 header.b=YEB4pKEt; spf=pass (mx1.freebsd.org: domain of pete@nomadlogic.org designates 66.165.241.226 as permitted sender) smtp.mailfrom=pete@nomadlogic.org; dmarc=pass (policy=quarantine) header.from=nomadlogic.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nomadlogic.org; s=04242021; t=1747147374; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=7gm+Rg2JnY+dQlhjCylCcfzvvRDyQI2isuV+81ZY8p4=; b=YEB4pKEtEDyL0pmu849OKcz3kP6cxn3gViVgamOwoZ189C5/BfrvAXfbpuZZjyI4hDpGIT RpT/vsGEvC1jNo3uwp+pQEPRsiOYB5G1xXhiPtE2BQoZfwuUg0B4dIuoaVeHK1dp+vF8OD onuH4x3Zn7BQBD8iokYvRprtSb0cwIY= Received: from [192.168.1.182] (47-154-20-141.fdr01.snmn.ca.ip.frontiernet.net [47.154.20.141]) by mail.nomadlogic.org (OpenSMTPD) with ESMTPSA id 38881baf (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Tue, 13 May 2025 14:42:53 +0000 (UTC) Message-ID: Date: Tue, 13 May 2025 07:43:07 -0700 List-Id: FreeBSD on cloud platforms (EC2, GCE, Azure, etc.) List-Archive: https://lists.freebsd.org/archives/freebsd-cloud List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-cloud@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: ena(4) tx timeout messages in dmesg To: "Kiyanovski, Arthur" , Colin Percival , "freebsd-cloud@freebsd.org" Cc: "Arinzon, David" References: <01000196c5b6fa5f-b8ed430e-23ca-47fd-9dd9-374a1de9c67c-000000@email.amazonses.com> <527aa929-4083-4935-8147-e59b6416c3bf@nomadlogic.org> <01000196c5db82dc-cfa5bf54-9758-4125-bdca-f1794b76ac9f-000000@email.amazonses.com> <1c8e7c62067845ab9cd5fca6198a78e8@amazon.com> Content-Language: en-US From: Pete Wright In-Reply-To: <1c8e7c62067845ab9cd5fca6198a78e8@amazon.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4ZxfNT1Tlsz3gjj X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.12 / 15.00]; NEURAL_HAM_SHORT(-0.92)[-0.917]; NEURAL_HAM_LONG(-0.71)[-0.706]; NEURAL_SPAM_MEDIUM(0.51)[0.508]; DMARC_POLICY_ALLOW(-0.50)[nomadlogic.org,quarantine]; R_SPF_ALLOW(-0.20)[+mx]; R_DKIM_ALLOW(-0.20)[nomadlogic.org:s=04242021]; MIME_GOOD(-0.10)[text/plain]; ASN(0.00)[asn:29802, ipnet:66.165.240.0/22, country:US]; ARC_NA(0.00)[]; TO_DN_SOME(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-cloud@freebsd.org]; DKIM_TRACE(0.00)[nomadlogic.org:+] On 5/12/25 19:52, Kiyanovski, Arthur wrote: >> ---------- Forwarded message --------- >> From: Pete Wright >> Date: Mon, 12 May 2025 at 12:30 >> Subject: Re: ena(4) tx timeout messages in dmesg >> To: Colin Percival , >> Cc: Arthur Kiyanovski >> >> >> >> >> On 5/12/25 11:56, Colin Percival wrote: >>> On 5/12/25 11:25, Pete Wright wrote: >>>> On 5/12/25 11:17, Colin Percival wrote: >>>>> On 5/12/25 11:04, Pete Wright wrote: >>>>>> hey there - i have an ec2 instance that i'm using as a nfs server >>>>>> and have noticed the following messages in my dmesg buffer: >>>>>> [...] >>>>>> ena0: Found a Tx that wasn't completed on time, qid 3, index 998. 1 >>>>>> msecs have passed since last cleanup. Missing Tx timeout value 5000 >>>>>> msecs. >>>>>> >>>>> I've heard that this can be caused by a thread being starved for >>>>> CPU, possibly due to FreeBSD kernel scheduler issues, but that was >>>>> on a far more heavily loaded system. What instance type are you >>>>> running on? >>>> >>>> oh of course, forgot to provide useful info: >>>> >>>> # uname -ar >>>> FreeBSD airflow-nfs.q0.ringdna.net 14.2-RELEASE-p1 FreeBSD 14.2- >>>> RELEASE-p1 GENERIC amd64 >>>> >>>> Instance type: >>>> t3a.xlarge >>>> >>>> I also verified I have plenty of available "burstable credit" >>>> available since this is a t class system (current balance is steady >>>> at >>>> 2,300 credits). >>> >>> Ah, this won't necessarily help you -- T family instances are on >>> shared hardware so even if you have burstable credits it's possible >>> that you'll be unlucky with "noisy neighbours" and the sibling >>> instances will all want CPU at the same time as you. But I think >>> there's probably something else going on as well. >>> >> >> >> oh that's a good point, since this is a pre-prod system that is less of a concern >> as we want to limit spend when possible. i'll be spinning up production >> systems in the following week or so that will be on a "c" >> class system, i'll keep an eye out to see if see similar messages in that >> environment. >> >> -pete >> >> -- >> Pete Wright >> pete@nomadlogic.org > > HI Colin, Pete, > > Your analysis regarding CPU being occupied is the classic explanation for this kind > prints. > > The prints are consistent with cpu not being available to the interrupt > handler to run. > Although you say you have burstable credits available, the fact that you are using > T instance types does make you more susceptible to such issues. > > Also when you say you have 25% CPU usage, how did you check that? > Are you using tools that give you an average over some time? so you may > have 75% of the time 0 cpu usage and 25% of the time 100% cpu usage. > > As you already suggested, the first thing we would like to eliminate is the T instance > Type. > If all works - great! > > If not you may want to look into the spreading of interrupts over the different cpus > using https://github.com/amzn/amzn-drivers/tree/master/kernel/fbsd/ena#io-irq-affinity > And also make sure that the cpu heavy processes you have, are run on different cpus than > ones you handle the interrupts on. > > Hope this helps, > Arthur > > > thanks for the context Arthur, I'll take a look at that sysctl knob. as i said the box is only serving a python virtual environment to a pool of ec2 compute nodes, and the dataset resides in memory. so nothing too crazy. the load does have spikes but they are pretty brief and rarely over %70. i'm collecting metrics via telegraph, and also observe load via the usual suspects like top, systat etc. it sounds like ena(4) seems to be particularly sensitive to cpu spikes though - at least with this vm configuration. if i continue to see these messages in dmesg i'll test out distributing IRQ's, otherwise i think i can chalk this up to a noisy neighbor or something similar. thanks! -pete -- Pete Wright pete@nomadlogic.org