Re: Discussion about NameNode Fine-grained locking

A0%E6%B5%A9%E5%8D%9A&uid=hfutzhanghb%40163.com&iconUrl=https%3A%2F%2Fmail-online.nosdn.127.net%2Fsmc804eb39b0e7885aa8801c3bb66e497d.jpg&items=%5B%22hfutzhanghb%40163.com%22%5D> >> >> Replied Message ---- >> From haiyang hu >> Date 12/31/2024 23:08 >> To Ay

Re: Discussion about NameNode Fine-grained locking

> From haiyang hu > Date 12/31/2024 23:08 > To Ayush Saxena > Cc Hui Fei , > ZanderXu , > Hdfs-dev , > , > Xiaoqiao He , > slfan1989 , > > Subject Re: Discussion about NameNode Fine-grained locking > Thanks for your hard work and push it forward

Re: Discussion about NameNode Fine-grained locking

Thanks for your hard work and push it forward. It looks good, +1 for merging phase 1 codes, hope we can work together to promote this major HDFS optimization, so that more companies can benefit from it. Thanks everyone~ Ayush Saxena 于2024年12月31日周二 20:33写道： > +1, > Thanx folks for your efforts o

Re: Discussion about NameNode Fine-grained locking

+1, Thanx folks for your efforts on this! I didn't have time to review everything thoroughly, but my initial pass suggests it looks good or atleast is safe to merge. If I find some spare time, I'll test it further and submit a ticket or so if I encounter any issues. Good Luck!!! -Ayush On Tue, 3

Re: Discussion about NameNode Fine-grained locking

Thanks Zander for bringing this discussion again and trying your best to push it forward. It's really a long time since last discussion. It’s indeed time, +1 for merging phase 1 codes based on the following points - The phase 1 feature has been running at scale within companies for a long time -

Re: Discussion about NameNode Fine-grained locking

Hi, everyone: Time to Merge FGL Phase I The PR for *FGL Phase I* is ready for merging! Please take a moment to review and cast your vote: https://github.com/apache/hadoop/pull/6762. The *FGL Phase I* has been running successfully in production for over six months at *Shopee* and *BOSS Zhipin*, wi

Re: Discussion about NameNode Fine-grained locking

I plan to hold a meeting on 2024-06-06 from 3:00 PM - 4:00 PM to share the FGL's motivations and some concerns in detail in Chinese. The doc is : NameNode Fine-Grained Locking Based On Directory Tree (II)

Re: Discussion about NameNode Fine-grained locking

BTW, there is a Slack channel hdfs-fgl for this feature. can join it and discuss more details. Is it necessary to hold a meeting to discuss this? So that we can push it forward quickly. Agreed with ZanderXu, it seems inefficient to discuss details via email list. Hui Fei 于2024年5月6日周一 23:50写道：

Re: Discussion about NameNode Fine-grained locking

Thanks all Seems all concerns are related to the stage 2. We can address these and make it more clear before we start it. >From development experience, I think it is reasonable to split the big feature into several stages. And stage 1 is also independent and it also can be as a minor feature that

Re: Discussion about NameNode Fine-grained locking

Thanks @Ayush Saxena and @Xiaoqiao He for your nice questions. Let me summarize your concerns and corresponding solutions: *1. Questions about the Snapshot feature* It's difficult to apply the FGL to Snapshot feature, but we can just using the global FS write lock to make it thread safe. So if

Re: Discussion about NameNode Fine-grained locking

Thanx Everyone for chasing this, Great to see some momentum around FGL, that should be a great improvement. I have some two broad categories: ** About the process:* I think in the above mails, there are mentions that phase one is complete in a feature branch & we are gonna merge that to trunk. If

Re: Discussion about NameNode Fine-grained locking

Thanks ZanderXu and Hui Fei for your work on this feature. It will be a very helpful improvement for the HDFS module in the next journal. 1. If we need any more review bandwidth, I would like to be involved to help review if possible. 2. From the design document there are still missing some detail

Re: Discussion about NameNode Fine-grained locking

Thanks for interest and advice on this. Just would like to share some info here ZanderXu leads this feature and he has spent a lot of time on it. He is the main developer in stage 1. Yuanboliu and Kokonguyen191 also took some tasks. Other developers (slfan1989 haiyang1987 huangzhaobo99 RocMarsha

Re: Discussion about NameNode Fine-grained locking

We have created a "hdfs-fgl" channel in slack that you can join to discuss FGL efficiently. On Fri, 26 Apr 2024 at 14:56, Zengqiang XU wrote: > Thanks Shilun for your response: > > 1. This is a big and very useful feature, so it really needs more > developers to get on board. > 2. This fine grai

Re: Discussion about NameNode Fine-grained locking

Thanks Shilun for your response: 1. This is a big and very useful feature, so it really needs more developers to get on board. 2. This fine grained lock has been implemented based on internal branches and has gained benefits by many companies, such as: Meituan, Kuaishou, Bytedance, etc. But it ha

Re: Discussion about NameNode Fine-grained locking

Thank you for your hard work! This is a very meaningful improvement, and from the design document, we can see a significant increase in HDFS read/write throughput. I am happy to see the progress made on HDFS-17384. However, I still have some concerns, which roughly involve the following aspects:

Re: Discussion about NameNode Fine-grained locking

cc private@h.a.o. On Wed, Apr 24, 2024 at 3:35 PM ZanderXu wrote: > > Here are some summaries about the first phase: > 1. There are no big changes in this phase > 2. This phase just uses FS lock and BM lock to replace the original global > lock > 3. It's useful to improve the performance, since s

Re: Discussion about NameNode Fine-grained locking

Here are some summaries about the first phase: 1. There are no big changes in this phase 2. This phase just uses FS lock and BM lock to replace the original global lock 3. It's useful to improve the performance, since some operations just need to hold FS lock or BM lock instead of the global lock 4

Re: Discussion about NameNode Fine-grained locking

Thanks Yuanbo for your response. Since the snapshot、symbol link is not popular in HADOOP Actually, Snapshot and Symbol are both enabled by many companies. I don't have information if the 'reserved' feature is also used. we can try to use global lock(write lock of root inode?) I think there are

Re: Discussion about NameNode Fine-grained locking

Thank you for sharing the information. My colleague mentioned that Tencent Kona 11 might have various improvements and we're interested to see what it's like. We would also like to try out shenandoah gc. - Takanobu 2024年3月6日(水) 15:17 Yuanbo Liu : > I've heard zgc is better in jdk17 or above, so

Re: Discussion about NameNode Fine-grained locking

I've heard zgc is better in jdk17 or above, so I think the major problem is that we have to upgrade hadoop code to fit in jdk17. We were using jdk11 with zgc to test NN, and didn't see an impressive improvement. On Wed, Mar 6, 2024 at 11:53 AM Takanobu Asanuma wrote: > > We're trying tuning gc o

Re: Discussion about NameNode Fine-grained locking

> We're trying tuning gc options and even new gc engine like zgc, but they are not very helpful. I'm afraid this is a digression, but could you elaborate on using ZGC for NameNode? Did you encounter any problems? I've never heard of using ZGC for NameNode in practice, so I'm curious about it. Reg

Re: Discussion about NameNode Fine-grained locking

> a. Snapshot, Symbolic link and reserved feature are not mentioned at the design doc, should it be considered Yes, I agree. Since the snapshot、symbol link is not popular in HADOOP, we can try to use global lock(write lock of root inode?). In our production env, we just ignore those features, but i

Re: Discussion about NameNode Fine-grained locking

Thanks for suggestions. Actually Started working on this improvement. And cut the development branch :) >From the proposal doc and the current reviewing work, seems that it doesn't touch the existing logic codes too much. It keeps the original logic there. @Yuanbo @Zengqiang XU Could you share

Re: Discussion about NameNode Fine-grained locking

Thanks for this meaningful proposal. Some nit comments: a. Snapshot, Symbolic link and reserved feature are not mentioned at the design doc, should it be considered or different to this core design? b. For the benchmark result, what Read/Write request ratio? And do you meet any GC issues when reach

Re: Discussion about NameNode Fine-grained locking

Nice to see this feature brought up. We've implemented this feature internally and gained significant performance improvement. I'll be glad to work on some jiras if necessary. On Tue, Feb 20, 2024 at 4:41 PM ZanderXu wrote: > Thank you everyone for reviewing this ticket. > > I think if there ar

Re: Discussion about NameNode Fine-grained locking

Thank you everyone for reviewing this ticket. I think if there are no problems with the goal and the overall solution, we are ready to push this ticket forward and I will create some detailed sub-tasks for this ticket. I will split this project into three milestones to make this project cleaner f

Re: Discussion about NameNode Fine-grained locking

Thank you for raising the issue of this long-standing bottleneck, this will be a very important improvement! Hopefully can participate and push forward together. Best Regards~ Brahma Reddy Battula 于2024年2月3日周六 00:40写道： > Thanks for bringing this and considering all the history around this. > O

Re: Discussion about NameNode Fine-grained locking

Thanks for bringing this and considering all the history around this. One of the outstanding bottleneck(global lock) from a long time. Hopefully we can push forward this time. On Fri, Feb 2, 2024 at 12:23 PM Hui Fei wrote: > Thanks for driving this. It's very meaningful. The performance improv

Re: Discussion about NameNode Fine-grained locking

Thanks for driving this. It's very meaningful. The performance improvement looks very good. Many users are facing the write performance issue. As far as I know, some companies already implemented the similar idea on their internal branches. But the internal branch is very different from the commun