From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from [87.239.111.99] (localhost [127.0.0.1]) by dev.tarantool.org (Postfix) with ESMTP id A12DA6EC40; Mon, 7 Jun 2021 23:00:34 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org A12DA6EC40 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1623096034; bh=Yu0HgGAoEXEXlW4msIOEXbzBJSEMBECLGhGt2GeGZf4=; h=Date:To:References:In-Reply-To:Subject:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=bWFKt/7Oy05tkk9X7v6wjyDsA14FJxO0yWCtroEHiOxagBDvxGdp0FBaOzyd1LPbD 1D4IsdRqNG5C9iymKpE3cP0jHjhS03IawjklceoDDx4VKs7qHhHD8TAognLkaIP6xZ CIeK4TA7bG7jcCsjrlFWEfFEzZWo84Rg1WN3t460= Received: from mail-lf1-f41.google.com (mail-lf1-f41.google.com [209.85.167.41]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id 260366EC40 for ; Mon, 7 Jun 2021 23:00:33 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 260366EC40 Received: by mail-lf1-f41.google.com with SMTP id w33so28329089lfu.7 for ; Mon, 07 Jun 2021 13:00:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=kPdHx/LzQ8RcT//xSCP6wNowYKzxSL+VM4gpeJT5WXU=; b=OXrBhof12MhkF4TQxECLhl8S9rA7MQhZmkIgk/GTM3tiszMB1F0sgTdouM4U4IlWQb qhxbwT2OZ9bixPKtABFnM9EUNbqnLs2tsYki6YmP90sxgPQT15AS+GP3eK59SAefZTaF FMyHJZcloxyTuW6WR3Y2bR4Vdkw5fSMAcOKhDTPOZJ4yD4Ka5DIKE37MHnDEL16uPD4n lSq5F86BOS8ykpAiu1MfDc01um4YnjjIH1C7+majZsFBUmio06NdBeetA7E78in8qSup l79Tnccq9lnJOVCdUHk95Q43PPawh04UUCVwjCDmrRyW9QZeWMk8RLFSptMmiYtlnFYV Xe0w== X-Gm-Message-State: AOAM5316fThli5Ry+UNpyXD4deOhdra9uvvYHjv5aVtLOJtDBZI4aSYv GsTGpS+jZpG8EjXKM5nzQ4Xnn18XFtU= X-Google-Smtp-Source: ABdhPJwDhN2dLovyAkYH39l74g9/XMivHazOaDWMtaBtu0lBEB8QCaQiPSyMLD2CUV731NWfebELnw== X-Received: by 2002:ac2:5626:: with SMTP id b6mr13050825lff.275.1623096031655; Mon, 07 Jun 2021 13:00:31 -0700 (PDT) Received: from grain.localdomain ([5.18.171.94]) by smtp.gmail.com with ESMTPSA id j9sm1605473lfu.58.2021.06.07.13.00.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 07 Jun 2021 13:00:30 -0700 (PDT) Received: by grain.localdomain (Postfix, from userid 1000) id D7DF65A0042; Mon, 7 Jun 2021 23:00:29 +0300 (MSK) Date: Mon, 7 Jun 2021 23:00:29 +0300 To: Vladislav Shpilevoy Message-ID: References: <20210607155519.109626-1-gorcunov@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/2.0.7 (2021-05-04) Subject: Re: [Tarantool-patches] [PATCH v8 0/2] relay: provide downstream lag information X-BeenThere: tarantool-patches@dev.tarantool.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Cyrill Gorcunov via Tarantool-patches Reply-To: Cyrill Gorcunov Cc: tml Errors-To: tarantool-patches-bounces@dev.tarantool.org Sender: "Tarantool-patches" On Mon, Jun 07, 2021 at 09:20:50PM +0200, Vladislav Shpilevoy wrote: > Hi! Thanks for the patchset! > > Please, provide branch and issue links next time. > https://github.com/tarantool/tarantool/wiki/Code-review-procedure#sending-the-patch > > I assume your branch is gorcunov/gh-5447-relay-lag-8. It was there, letme quote it for you, I think you might simply miss it from a glance > branch gorcunov/gh-5447-relay-lag-8 > issue https://github.com/tarantool/tarantool/issues/5447 > It seems after your changes some tests start failing. Looks > like you didn't clear artifacts of your new test. > https://github.com/tarantool/tarantool/runs/2765786321 I'll take a look, thanks! > On 07.06.2021 17:55, Cyrill Gorcunov wrote: > > Guys, take a look once time permit. Previous version is here > > > > https://lists.tarantool.org/tarantool-patches/20210506214132.533913-1-gorcunov@gmail.com/ > > > > I still think we might need some general statistics engine because this > > lag rather common data and we could move other "last" things like last_row_time > > there but since I didn't get approve on the idea I keep the timestamp > > in replica structure. > > If you are talking about your perf metrics engine which we tried to > design for replication, it was approved. The problem is that there was > no a really good design on how should it look and work. Not perf metrics (as we were discussed time back then seems plain perf is more than enough for most of developers if I'm not mistaken). I rather though of my previous RFC where I proposed to have some common and shared "stat" engine with rw operations: > Not for merging yet! I think instead of applier_wal_stat structure we might need some > _commonly shared_ statistics structure, probably bound to WAL code and all other > threads will update it in a lockless way, because we might need to collect more > detais on WAL processing in future. I though of something like > > enum { > WAL_ICNT__APPLIER_TXN_START_TM, > > WAL_ICNT__MAX, > }; > > struct wal_stat { > int64_t icnt[WAL_ICNT__MAX]; > } wal_st[VCLOCK_MAX]; > > and introduce > > wal_st__icnt_read(unsigned id); > wal_st__icnt_write(unsigned id); > > then applier will simply push last timestamp to WAL_ICNT__APPLIER_TXN_START_TM > counter, and later when we need to send ACK we use wal_st__icnt_read() to > fetch it back. We won't need to allocate some dynamic memory for it but > rather use statically preallocated shared between threads.