When will fdb 7.3 be officially released as a production version?

Using FoundationDB
1

Is any time scheduled?

2

Maybe @jzhou can answer your question about official release plans, but Snowflake is already using a variation of 7.3 in production, from the snowflake/release-71.3 branch which was created from main some time prior to release-7.3.

3

We have almost validated 7.3. Maybe in another couple of weeks, after we roll out to production clusters, we’ll mark 7.3 as production release.

6 Likes
4

Tag 7.3.27 marked as latest. It’s mean that is stable release now?
When documentation will be updated? Current documentation don’t cover all features from latest release,
for example blob granule.

5

Does 7.3 also contain the improvement of 7.2., e.g.:
Read-aware Data Distribution feature is developed for balance the read bytes bandwidth among storage servers

6

When can we expect a stable production-ready version of Foundationdb 7.3.X?

7

Any release news? @jzhou

8

7.3.27 is stable and runs in a few clusters in production. However, we know there is a problem of missing client metrics (no server side issues), which we are actively investigating. Once solved, we’ll mark a new release as the latest stable version and start wider rollout.

3 Likes
9

@jzhou - Any news relating to the 7.3.X release version? Which version is considered as the stable, production-ready for teams to deploy?

10

We finally fixed the metrics issue. The upcoming 7.3.42/43 releases will hopefully be production-ready.

11 Likes
11

Is there a production ready 7.3.x build available now?

12

7.3.43 was released.

1 Like
13

7.3.43 has the ‘pre-release’ tag. Is this release considered stable/production-ready?

1 Like
14

7.3.43 has fixed the client metric issue. However, our testing on REHL9 (newer kernel vs. old one) shows frequent OOMs for storage servers, which is under investigation and might need patches.

15

The OOM issue was caused by Linux kernel’s Transparent Huge Page (THP) feature. Changing THP flag to madvise solves the problem:

# echo madvise > /sys/kernel/mm/transparent_hugepage/enabled

After the change, bounce all fdbserver processes:

fdbcli> kill; kill all
3 Likes
17

Does this option need to be enabled in version 7.1?

18

Depends on your deployment. If there are OOMs of storage servers, then making the change will probably solve the issue. Otherwise, no changes are needed. In a different thread, it was mentioned that THP might have some performance gains.

19

We’ve found that 7.3.43 on Amazon Linux 2023 still exhibits this behaviour even with /sys/kernel/mm/transparent_hugepage/enabled set to madvise. Did you make any additional changes to resolve this?

In the same environment, we found that 7.3.37 does not exhibit this behaviour and behaves as expected.