Updated to version 3.2.1.x
Introduction
Elastifile Cloud File System supports advisory file locking, lock requests and partial range locks per file.
As with every system resources the resources that are allocated to this functionality are limited and in certain scenarios can impact the customer environment.
The following document describes these limitations
Connection per system frontend cores
Each storage node's cores are evenly split into frontend and backend cores. Frontend cores are responsible for client connection termination, protocol termination and file locks functionality.
While each node can handle up to 1000 clients connections, if locking functionality is uses the actual number of connections is limited as follows:
There is a limit of 100 client connections (ip address granularity) per core.
-- blocking locks - resource (pool) that is being taken for maintaining a list of clients that are pending for a lock to be released - up to 100 connections from different client IP addresses.
-- non-blocking locks - there is a small time period where this resource is being taken (before parsing the lock request), however it is released when replying to the client. limit of 100 concurrent requests from different client IP addresses.
In terms of different nodes configurations in GCP the limitations per nodes are as follows
|
Configuration |
Instance Type |
# CPUs |
# FE cors |
Concurrent request or concurrent waiters for Blocking locks |
Concurrent requests for Non-Blocking locks |
|
Small (Persistent-SSD) |
Custom |
4 |
2 |
200 |
200 |
|
Medium (Persistent-SSD) |
Custom |
4 |
2 |
200 |
200 |
|
Medium Plus (Persistent-SSD) |
Custom |
8 |
4 |
400 |
400 |
|
Large (Persistent-SSD) |
N1-highmem 16 |
16 |
8 |
800 |
800 |
|
Local SSD |
Custom |
16 |
8 |
800 |
800 |
|
Small Local SSD |
Custom |
4 |
2 |
200 |
200 |
|
Standard PDs* |
Custom |
4 |
2 |
200 |
200 |
|
Small Standard PDs* |
Custom |
4 |
2 |
200 |
200 |
* These configurations are not for production and will be removed in following versions
Number of active locks per file
For each file there is an aux file that holds the current active locks on the file. The file limit is 32KB and the number of locks it can hold depends on the identification of the locking client and the locking application.
The formula for the file structure is as follows
Lock entry = 11
+ for each holder: 43 + owner (identify owner of a lock) + caller_name - Holder is a client currently holding a lock
+ for each waiter: 47 + owner (identify owner of a lock) + caller_name - Waiter is a client waiting for a lock request approval for an already locked file or range
+ for each share: 28 + owner (identify owner of a lock) + caller_name - Share reservation for the entire file
caller_name is usually the hostname, the owner is usually pid@hostname and the Client ID or Application ID can't be longer than 1024
For example
In the example below twe assume the caller_name and owner ID are the same lengths. And the number of max locks is taken as the worst case of all waiters. The actual number of possible locks is in between the numbers in the example.
-
worst case id==1024
Max locks* per file <= 15
-
case id==100
Max locks* per file <= 132
-
case id==10
Max locks* per file<= 488
The sum of locks in any of the stages - holders, waiters or shares