monitor metric review

[????????????]

HI,


Please help review the code.


Under the existing metirc framework, some new system and process metrics like 
sys_free_physical_memory_size, process_mem_ratio, and sys_disk_free_space have 
been added, which will provide more useful information helping us resolving 
system problems, detecting potential system risks and enhancing system 
stability.


PR: 
https://github.com/apache/iotdb/pull/5406/files#diff-21aadf817eed8be94a3bf9a72ff626bf56fb53190a1be4262627f4fc581e8a41




zhenqiang 
CISDI INFO

About replacing byteBuffer

[李思佳]

Hi all,

When I was developing the snapshot interface for the configNode module, I 
noticed that the parameters received by the serialization interface were all 
defined as ByteBuffer, which seemed to have some problems. For example, the 
external main process has no way of knowing how big the buffer will be. We can 
only estimate a large value to allocate memory.

 Then I looked at the serialization interfaces of other modules, and it seemed 
that most modules did the same thing. This could be a problem once the actual 
size of the buffer exceeds our estimate. So I did a quick survey of Netty's 
byteBuf last week, and here's the Chinese version of the 
results.

  At the same time, we found that the consensus module also has some ByteBuf 
requirements. But byteBuf doesn't seem to be enough to give us precise control 
over the size of the memory pool, and we may need to wrap it if we decide to 
use it.

  Finally, we decided to use stream type instead of byteBuffer in configNode 
for the time being. I will start this work to see if this is the better way 
this week. If any idea, please let me know.

  By the way, Netty’s ByteBuf provides powerful tool operations that we will 
not discard outright, but rather as an option.

BR,
---
Sijia Li

Re: About replacing byteBuffer

[Jialin Qiao]

Hi,

The serialization interface needs to be refactored afterward.

Before that, using ByteArrayOutputStream is easier.

Thanks,
—
Jialin Qiao
Apache IoTDB PMC


李思佳  于2022年5月16日周一 11:44写道：

> Hi all,
>
> When I was developing the snapshot interface for the configNode module, I
> noticed that the parameters received by the serialization interface were
> all defined as ByteBuffer, which seemed to have some problems. For example,
> the external main process has no way of knowing how big the buffer will be.
> We can only estimate a large value to allocate memory.
>
>  Then I looked at the serialization interfaces of other modules, and it
> seemed that most modules did the same thing. This could be a problem once
> the actual size of the buffer exceeds our estimate. So I did a quick survey
> of Netty's byteBuf last week, and here's the Chinese version of the results<
> https://apache-iotdb.feishu.cn/docs/doccnW1EFoyLOScys9GTOuaEUbh>.
>
>   At the same time, we found that the consensus module also has some
> ByteBuf requirements. But byteBuf doesn't seem to be enough to give us
> precise control over the size of the memory pool, and we may need to wrap
> it if we decide to use it.
>
>   Finally, we decided to use stream type instead of byteBuffer in
> configNode for the time being. I will start this work to see if this is the
> better way this week. If any idea, please let me know.
>
>   By the way, Netty’s ByteBuf provides powerful tool operations that we
> will not discard outright, but rather as an option.
>
> BR,
> ---
> Sijia Li
>
>

Re: maintain the IoTDB-Skywalking plugin codes

[Jialin Qiao]

+1 for apache/iotdb-skywalking-storage
—
Jialin Qiao
Apache IoTDB PMC


HW-Chao Wang <576749...@qq.com.invalid> 于2022年5月13日周五 21:09写道：

> thanks Skywalking community. i feel should be
> apache/iotdb-skywalking-storage.skywalking be not a required module for
> iotdb，separate from apache/iotdb.
>
>
>
> ---Original---
> From: "Xiangdong Huang" Date: Fri, May 13, 2022 17:37 PM
> To: "dev" Subject: maintain the IoTDB-Skywalking plugin codes
>
>
> Hi all,
>
> Skywalking community is discussing about only keeping self-implemented
> storage layer.
>
> IMO, I think it is not a bad decision to remove 3rd-part implementataion
> from skywalking's main repo.  Because we can decide which version of
> skywalking we can maintain according to the community developers' time.
> However, IoTDB-skywalking integration has its meaning and we should keep to
> maintain the integration.
>
> The discussion is, where to put the integration to?
>
> a new code repo like: apache/iotdb-skywalking-storage?
> or into IoTDB's repo like apache/iotdb/skywalking?
>
> [1] https://github.com/apache/skywalking/discussions/9059
>
> Best,
> ---
> Xiangdong Huang
> School of Software, Tsinghua University
>
>  黄向东
> 清华大学 软件学院

[BUILD-UNSTABLE]: Job 'IoTDB/IoTDB-Pipe/master [master] [595]'

[Apache Jenkins Server]

BUILD-UNSTABLE: Job 'IoTDB/IoTDB-Pipe/master [master] [595]':

Check console output at "https://ci-builds.apache.org/job/IoTDB/job/IoTDB-Pipe/job/master/595/";>IoTDB/IoTDB-Pipe/master
 [master] [595]"