I am new in hadoop and i am not yet familiar to its configuration.
I just want to ask the maximum container per node.
I am using a single node cluster (6GB ram laptop)
and below is my mapred and yarn configuration:
**mapred-site.xml**
map-mb : 4096 opts:-Xmx3072m
reduce-mb : 8192 opts:-Xmx6144m
**yarn-site.xml**
resource memory-mb : 40GB
min allocation-mb : 1GB
The above setup can only run 4 to 5 jobs. and max of 8 container.
Maximum containers that run on a single NodeManager (hadoop worker) depends on lot of factors like how much memory is assigned for the NodeManager to use and also depends on application specific requirements.
The defaults for yarn.scheduler.*-allocation-* are: 1GB (minimum allocation), 8GB (maximum allocation), 1 core and 32 cores. So, minimum and maximum allocation, affects number of containers per node.
So, if you have 6GB RAM and 4 virtual cores, here is how the YARN configuration should look like:
yarn.scheduler.minimum-allocation-mb: 128
yarn.scheduler.maximum-allocation-mb: 2048
yarn.scheduler.minimum-allocation-vcores: 1
yarn.scheduler.maximum-allocation-vcores: 2
yarn.nodemanager.resource.memory-mb: 4096
yarn.nodemanager.resource.cpu-vcores: 4
The above configuration tells hadoop to use atmost 4GB and 4 virtual cores and that each container can have between 128 MB and 2 GB of memory and between 1 and 2 virtual cores, with these settings you could run upto 2 containers with maximum resources at a time.
Now, for MapReduce specific configuration:
yarn.app.mapreduce.am.resource.mb: 1024
yarn.app.mapreduce.am.command-opts: -Xmx768m
mapreduce.[map|reduce].cpu.vcores: 1
mapreduce.[map|reduce].memory.mb: 1024
mapreduce.[map|reduce].java.opts: -Xmx768m
With this configuration, you could theoretically have up to 4 mappers/reducers running simultaneously in 4 1GB containers. In practice, the MapReduce application master will use a 1GB container so the actual number of concurrent mappers and reducers will be limited to 3. You can play around with the memory limits but it might require some experimentation to find the best ones.
As a rule of thumb, you should limit the heap-size to about 75% of the total memory available to ensure things run more smoothly.
You could also set memory per container using yarn.scheduler.minimum-allocation-mb property.
For more detail configuration for production systems use this document from hortonworks as a reference.
Related
I am looking for suggestions on my RocksDB configuration. Our use case is to load 100GB of key-value pairs into rocksdb and at run time only serve the key-value pairs in the db. Key is 32 bytes and value is 1.6 KB in size.
What we have right now is we used hadoop to generate a 100GB sst file using SstFileWriter api and save it off in S3. Each new server that comes up ingests the file using: db.ingestExternalFile(..). We use a i3.large machine (15.25 GiB | 2 vCPUs | 475 GiB NVMe SSD). P95 and avg response from rocksdb given the current configuration:
BlockSize = 2KB
FormatVersion = 4
Read-Write=100% read at runtime
is ~1ms but P99 and PMAX are pretty bad. We are looking for some way to reduce the PMAX response times which is ~10x P95.
Thanks.
Can you load all of the db in memory using tmpfs ... basically just copy the data to RAM and see if that helps .... also it may make sense to compact the sst files in a separate job rather than ingesting at startup ... this may need a change in your machine config to be geared more towards RAM and less towards SSD storage
I'm reading all the rows from already created Ignite cache having 1M key value pairs. When I read it from the same network on which ignite cluster is running, it is taking around 20 second. However, when I read it from a machine, outside the network on which ignite cluster is running, it is taking 10 minutes. The size of whole cache is around 100 MB. I tried testing the bandwidth between the ignite cluster network and outside network by transferring file of size 100MB. It took only 5 seconds. I am wondering why Ignite is taking whopping 600 seconds to transfer the all key-value pairs from the cache?
//cache configuration
CacheConfiguration<BenchmarkCacheStoreKey, OptionalDouble> cfg = new CacheConfiguration<BenchmarkCacheStoreKey, OptionalDouble>();
cfg.setName(cacheName);
cfg.setCacheMode(CacheMode.PARTITIONED);
//1 backup of each cache
cfg.setBackups(1);
cfg.setStatisticsEnabled(true);
cfg.setAtomicityMode(CacheAtomicityMode.ATOMIC);
cfg.setGroupName(CACHE_GROUP_NAME);
cfg.setWriteSynchronizationMode(CacheWriteSynchronizationMode.FULL_SYNC);
//do not blockk read/write for cache rebalancing
cfg.setRebalanceMode(CacheRebalanceMode.ASYNC);
Logic to read from cache below:
Map<K, V> readMap = new HashMap<>();
IgniteCache cache = ignite.cache(cacheName)
cache.forEach(action ->readMap.put(action.getKey(), action.getValue()));
Try to split you file on 1M parts and transfer it again by parts. I think this time you would have result similar to 10 minutes.
cache.forEach(action ->readMap.put(action.getKey(),
action.getValue()));
forEach does scan query, by default scan query has page size == 1024, you can try to increase it, it will increase batching size, you can do it like this:
cache.query(new ScanQuery<>().setPageSize(10_240));
It's a cluster solution, all defaults are configured to work in the same network, so if you have bad network and run client in different cluster than server, then you might need to tweak it.
However, instead of moving data to client, it's better to send compute task to server and return some small result to client if this possible.
Could anybody explain me the optimal configuration and parallelism for high performance flink jobs on YARN?
I use Cloudera Hadoop with 4 nodes (1 main node + 3 worker nodes) each has 12 CPU and 96 Gb memory.
There are few yarn properties
yarn.scheduler.maximum-allocation-mb - current value is 36Gb
yarn.nodemanager.resource.memory-mb - current value is 36Gb
I have found out that when I start yarn-session I should set -tm flag no more than 36Gb or my application will fail with error The cluster does not have the requested resources for the TaskManagers available! Maximum Memory: <...> Requested: <...>MB . Please check the 'yarn.scheduler.maximum-allocation-mb' and the 'yarn.nodemanager.resource.memory-mb' configuration values otherwise.
I want to use all of resources available on the cluster to increase performance of my flink jobs. So my questions are:
Should I set the above properties almost to 96 Gb (i.e. 88 Gb) and use 1 TaskManager per worker node with 12 slots (3 TaskManagers on 3 nodes, 36 slots total)? Is it common to use huge TaskManagers on YARN?
Or should I set yarn.nodemanager.resource.memory-mb to 88 Gb and yarn.scheduler.maximum-allocation-mb to 8 Gb and use multiple TaskManagers per one worker node? For example, 6 TaskManagers per node with 2 slots each (18 TaskManagers on 3 nodes with 36 slots total)? I have read that it is not recommended to set too high value for yarn.scheduler.maximum-allocation-mb.
Is it enougth to set -jm flag to 4 Gb for flink session? Are there any recomendations for this?
Please explain, how does it impact on network traffic, garbage collection, CPU and memory utilization, etc? Which configuration should I use for best performance?
Thank you for any help!
I want to monitor my redis cache cluster on ElastiCache. From AWS/Elasticache i am able to get metrics like FreeableMemory and BytesUsedForCache. If i am not wrong BytesUsedForCache is the memory used by cluster(assuming there is only one node in cluster). I want to calculate percentage uses of memory. Can any one help me to get percentage of Memory uses in Redis.
We had the same issue since we wanted to monitor the percentage of ElastiCache Redis memory that is consumed by our data.
As you wrote correctly, you need to look at BytesUsedForCache - that is the amount of memory (in bytes) consumed by the data you've stored in Redis.
The other two important numbers are
The available RAM of the AWS instance type you use for your ElastiCache node, see https://aws.amazon.com/elasticache/pricing/
Your value for parameter reserved-memory-percent (check your ElastiCache parameter group). That's the percentage of RAM that is reserved for "nondata purposes", i.e. for the OS and whatever AWS needs to run there to manage your ElastiCache node. By default this is 25 %. See https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/redis-memory-management.html#redis-memory-management-parameters
So the total available memory for your data in ElastiCache is
(100 - reserved-memory-percent) * instance-RAM-size
(In our case, we use instance type cache.r5.2xlarge with 52,82 GB RAM, and we have the default setting of reserved-memory-percent = 25%.
Checking with the info command in Redis I see that maxmemory_human = 39.61 GB, which is equal to 75 % of 52,82 GB.)
So the ratio of used memory to available memory is
BytesUsedForCache / ((100 - reserved-memory-percent) * instance-RAM-size)
By comparing the freeableMemory and bytesUsedForCache metrics, you will have the available memory for the Elasticache non-cluster mode (not sure if it applies to cluster-mode too).
Here is the NRQL we're using to monitor the cache:
SELECT Max(`provider.bytesUsedForCache.Sum`) / (Max(`provider.bytesUsedForCache.Sum`) + Min(`provider.freeableMemory.Sum`)) * 100 FROM DatastoreSample WHERE provider = 'ElastiCacheRedisNode'
This is based on the following:
FreeableMemory: The amount of free memory available on the host. This is derived from the RAM, buffers and cache that the OS reports as freeable.AWS CacheMetrics HostLevel
BytesUsedForCache: The total number of bytes allocated by Redis for all purposes, including the dataset, buffers, etc. This is derived from used_memory statistic at Redis INFO.AWS CacheMetrics Redis
So BytesUsedForCache (amount of memory used by Redis) + FreeableMemory (amount of data that Redis can have access to) = total memory that Redis can use.
With the release of the 18 additional CloudWatch metrics, you can now use DatabaseMemoryUsagePercentage and see the percentage of memory utilization in redis.
View more about the metric in the memory section here
You would have to calculate this based on the size of the node you have selected. See these 2 posts for more information.
Pricing doc gives you the size of your setup.
https://aws.amazon.com/elasticache/pricing/
https://forums.aws.amazon.com/thread.jspa?threadID=141154
We are using Redis 1.2.6 in production environment. There are 161804 keys in redis. Machine has 2GB RAM.
Problem:
Select queries to Redis are taking 0.02 sec on an average. But some times they take 1.5-2.0 secs, I think whenever redis save modified keys on disk.
One strange thing I noticed before and after restarting the redis is that:
Before restart "changes_since_last_save" changing too fast and was reaching 3000+ (in 5 minutes). But after restart "changes_since_last_save" remains below 20 or so.
Redis stats before restart:
{:bgrewriteaof_in_progress=>"0", :arch_bits=>"64", :used_memory=>"53288487", :total_connections_received=>"586171", :multiplexing_api=>"epoll", :used_memory_human=>"50.82M", :total_commands_processed=>"54714152", :uptime_in_seconds=>"1629606", :changes_since_last_save=>"3142", :role=>"master", :uptime_in_days=>"18", :bgsave_in_progress=>"0", :db0=>"keys=161863,expires=10614", :connected_clients=>"13", :last_save_time=>"1280912841", :redis_version=>"1.2.6", :connected_slaves=>"1"}
Redis stats after restart:
{:used_memory_human=>"49.92M", :total_commands_processed=>"6012", :uptime_in_seconds=>"1872", :changes_since_last_save=>"2", :role=>"master", :uptime_in_days=>"0", :bgsave_in_progress=>"0", :db0=>"keys=161823,expires=10464", :connected_clients=>"13", :last_save_time=>"1280917477", :redis_version=>"1.2.6", :connected_slaves=>"1", :bgrewriteaof_in_progress=>"0", :arch_bits=>"64", :used_memory=>"52341658", :total_connections_received=>"252", :multiplexing_api=>"epoll"}
Not sure what is going wrong here.
Thanks in advance.
Sunil
By default Redis is configured to dump all data to disk from time to time depending on the amount of keys that changed in a time span (see the default config).
Another option is to use the append-only file, which is more lightweight but needs some kind of maintenance – you need to run BGREWRITEAOF every once in a while so that your log doesn't get too big. There's more on the Redis config file about this.
As Tobias says, you should switch to 2.0 as soon as you can since it's faster and, in many cases, uses less memory than 1.2.6.