Many thanks Gopal. Mich Talebzadeh
Sybase ASE 15 Gold Medal Award 2008 A Winning Strategy: Running the most Critical Financial Data on ASE 15 http://login.sybase.com/files/Product_Overviews/ASE-Winning-Strategy-091908. pdf Author of the books "A Practitioner's Guide to Upgrading to Sybase ASE 15", ISBN 978-0-9563693-0-7. co-author "Sybase Transact SQL Guidelines Best Practices", ISBN 978-0-9759693-0-4 Publications due shortly: Complex Event Processing in Heterogeneous Environments, ISBN: 978-0-9563693-3-8 Oracle and Sybase, Concepts and Contrasts, ISBN: 978-0-9563693-1-4, volume one out shortly http://talebzadehmich.wordpress.com NOTE: The information in this email is proprietary and confidential. This message is for the designated recipient only, if you are not the intended recipient, you should destroy it immediately. Any information in this message shall not be understood as given or endorsed by Peridale Technology Ltd, its subsidiaries or their employees, unless expressly so stated. It is the responsibility of the recipient to ensure that this email is virus free, therefore neither Peridale Ltd, its subsidiaries nor their employees accept any responsibility. -----Original Message----- From: Gopal Vijayaraghavan [mailto:go...@hortonworks.com] On Behalf Of Gopal Vijayaraghavan Sent: 13 October 2015 21:37 To: user@hive.apache.org Cc: Mich Talebzadeh <m...@peridale.co.uk> Subject: Re: Container is running beyond physical memory limits > Now I am rather confused about the following parameters (for example > mapreduce.reduce versus > mapreduce.map) and their correlation to each other They have no relationship with each other. They are meant for two different task types in MapReduce. In general you run fewer reducers than mappers, so they are given more memory per-task than mapppers - most commonly it's ~2x of the other, but they are not related in any way. The ideal numbers to use for both are exact multiples of yarn.scheduler.minimum-allocation-mb (since YARN rounds up to that quantum). For example, with a 1536 min-alloc, you're better off allocating 4608 & getting -Xmx3686, since the 4096 ask will anyway pad up to 4608, losing 500Mb in the process. This is very annoying & complex, so with Tez there's exactly 1 config & you can just skip the -Xmx param for hive.tez.java.opts. Tez will inject an Xmx after a container alloc returns (so that re-adjustment is automatic). > <property> > <name>mapreduce.map.memory.mb</name> > <value>4096</value> > </property> > > <property> > <name>mapreduce.reduce.memory.mb</name> > <value>8192</value> > </property> > > <property> > <name>mapreduce.map.java.opts</name> > <value>-Xmx3072m</value> > </property> > > <property> > <name>mapreduce.reduce.java.opts</name> > <value>-Xmx6144m</value> > </property> Those configs are correct, the GC heap is approximately 80% of the allocated container (the JVM uses non-GC buffers for operations like Zlib decompression). Cheers, Gopal
