Github user mridulm commented on a diff in the pull request: https://github.com/apache/spark/pull/16603#discussion_r96360466 --- Diff: core/src/main/java/org/apache/spark/memory/TaskMemoryManager.java --- @@ -144,23 +170,31 @@ public long acquireExecutionMemory(long required, MemoryConsumer consumer) { // spilling, avoid to have too many spilled files. if (got < required) { // Call spill() on other consumers to release memory + // Sort the consumers according their memory usage. So we avoid spilling the same consumer + // which is just spilled in last few times and re-spilling on it will produce many small + // spill files. + List<MemoryConsumer> sortedList = new ArrayList<>(); for (MemoryConsumer c: consumers) { if (c != consumer && c.getUsed() > 0 && c.getMode() == mode) { - try { - long released = c.spill(required - got, consumer); - if (released > 0) { - logger.debug("Task {} released {} from {} for {}", taskAttemptId, - Utils.bytesToString(released), c, consumer); - got += memoryManager.acquireExecutionMemory(required - got, taskAttemptId, mode); - if (got >= required) { - break; - } + sortedList.add(c); + } + } + Collections.sort(sortedList, new ConsumerComparator()); + for (MemoryConsumer c: sortedList) { + try { + long released = c.spill(required - got, consumer); + if (released > 0) { + logger.debug("Task {} released {} from {} for {}", taskAttemptId, + Utils.bytesToString(released), c, consumer); + got += memoryManager.acquireExecutionMemory(required - got, taskAttemptId, mode); + if (got >= required) { + break; } - } catch (IOException e) { - logger.error("error while calling spill() on " + c, e); - throw new OutOfMemoryError("error while calling spill() on " + c + " : " - + e.getMessage()); } + } catch (IOException e) { + logger.error("error while calling spill() on " + c, e); + throw new OutOfMemoryError("error while calling spill() on " + c + " : " + + e.getMessage()); } --- End diff -- Regarding proposal two to change to TreeSet (or TreeMap as elaborated above) instead of HashSet. If the ordering is dependent on something which changes - then ordering is not gauranteed : which is why, if you observe, I mentioned that each change in memory acquisition or release should remove and re-add the consumer to the set so that the invariant is re-established. This might have other impacts (difficulty to ensure this is consistently enforced, performance, etc) - which should be looked into before proceeding down that path. The benefit is the elimination of sorting (in current PR) or creation of TreeMap (I elaborated) each time we need to spill. Depending on how (un)common and expensive the latter is, we should take a call.
--- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- --------------------------------------------------------------------- To unsubscribe, e-mail: reviews-unsubscr...@spark.apache.org For additional commands, e-mail: reviews-h...@spark.apache.org