搜索[优化]结果-低调大师优秀个人博客

精选列表

搜索[优化]，共10000篇文章

YARN and MapReduce的【内存】优化配置详解

在Hadoop2.x中, YARN负责管理MapReduce中的资源(内存, CPU等)并且将其打包成Container。使之专注于其擅长的数据处理任务, 将无需考虑资源调度. 如下图所示 Y ARN会管理集群中所有机器的可用计算资源. 基于这些资源YARN会调度应用(比如MapReduce)发来的资源请求, 然后YARN会通过分配Co ntainer来给每个应用提供处理能力, Container是YARN中处理能力的基本单元, 是对内存, CPU等的封装. 目前我这里的服务器情况：6台slave，每台：32G内存，2*6核CPU。由于hadoop 1.x存在JobTracker和TaskTracker，资源管理有它们实现，在执行mapreduce作业时，资源分为map task和reduce task。所有存在下面两个参数分别设置每个TaskTracker可以运行的任务数：点击(此处)折叠或打开 <property> <name>mapred.tasktracker.map.tasks.maximum</name> <value>6</value> <description><![CDATA[CPU数量=服务器CPU总核数 / 每个CPU的核数；服务器CPU总核数 = more /proc/cpuinfo | grep 'processor' | wc -l；每个CPU的核数 = more /proc/cpui nfo | grep 'cpu cores']]></description> </property> <property> <name>mapred.tasktracker.reduce.tasks.maximum</name> <value>4</value> <description>一个task tracker最多可以同时运行的reduce任务数量</description> </property> 但是在hadoop 2.x中，引入了Yarn架构做资源管理，在每个节点上面运行NodeManager负责节点资源的分配，而slot也不再像1.x那样区分Map slot和Reduce slot。在Yarn上面Container是资源的分配的最小单元。 Yarn集群的内存分配配置在yarn-site.xml文件中配置：点击(此处)折叠或打开 <property> <name>yarn.nodemanager.resource.memory-mb</name> <value>22528</value> <discription>每个节点可用内存,单位MB</discription> </property> <property> <name>yarn.scheduler.minimum-allocation-mb</name> <value>1500</value> <discription>单个任务可申请最少内存，默认1024MB</discription> </property> <property> <name>yarn.scheduler.maximum-allocation-mb</name> <value>16384</value> <discription>单个任务可申请最大内存，默认8192MB</discription> </property> 由于我Yarn集群还需要跑Spark的任务，而Spark的Worker内存相对需要大些，所以需要调大单个任务的最大内存（默认为8G）。而Mapreduce的任务的内存配置：点击(此处)折叠或打开 <property> <name>mapreduce.map.memory.mb</name> <value>1500</value> <description>每个Map任务的物理内存限制</description> </property> <property> <name>mapreduce.reduce.memory.mb</name> <value>3000</value> <description>每个Reduce任务的物理内存限制</description> </property> <property> <name>mapreduce.map.java.opts</name> <value>-Xmx1200m</value> </property> <property> <name>mapreduce.reduce.java.opts</name> <value>-Xmx2600m</value> </property> mapreduce. map .memory.mb：每个 map 任务的内存，应该是大于或者等于 Container 的最小内存。按照上面的配置：每个slave可以运行 map 的数据<= 22528 / 1500 , reduce 任务的数量<= 22528/3000 。 mapreduce.map.memory.mb >mapreduce.map.java.optsmapreduce.reduce.memory.mb >mapreduce.reduce.java.opts mapreduce.map.java.opts / mapreduce.map.memory.mb =0.70~0.80mapreduce.reduce.java.opts / mapreduce.reduce.memory.mb =0.70~0.80 在yarn container这种模式下，JVM进程跑在container中，mapreduce.{map|reduce}.java.opts 能够通过Xmx设置JVM最大的heap的使用，一般设置为0.75倍的memory.mb，则预留些空间会存储java,scala code等。

2016-11-05

MaxCompute（原ODPS）任务优化之列裁剪

：https://www.aliyun.com/product/odps 转自kaiding 最近因为几个ODPS任务节点扣分严重，计算健康度一度堕落至85分的红线以下，上了一次黑榜，立马开始了艰苦的优化之旅

2016-10-26

Android App罕见错误和优化方案

优化方案： 1、能用FrameLayout的，都换成这个（因为Android会对此layout进行merge操作），同时能不用layout的也尽量不用2、纯色图片，能用xml写的，换用xml写，图片命令均以

2016-10-08

MySQL索引原理及慢查询优化

=和in可以乱序，比如a = 1 and b = 2 and c = 3 建立(a,b,c)索引可以任意顺序，mysql的查询优化器会帮你优化成索引可以识别的形式3.

2016-06-15

Hbase万亿级存储性能优化总结

总结下hbase优化(针对0.94版本)方面的一些经验也算对这两年hbase工作的一个描述。

2014-12-07

百度APP iOS端包体积50M优化实践(七)编译器优化

前言百度APP iOS端包体积优化系列文章的前六篇重点介绍了包体积优化整体方案、图片优化、资源优化、代码优化、无用类优化、HEIC图片优化实践和无用方法清理，图片优化是从无用图片、Asset Catalog

2023-12-05

优化技术专题-性能优化系列-针对Java对象压缩及序列化技术的探索之路

（Model) inputStream.readObject(); inputStream.close(); Kryo序列化框架（星耀级别） kryo根据上述Java原生序列化机制的一些问题，对了很多优化工作

2021-10-18

程序性能优化入门锦集--设计+代码+JVM调优+数据库优化策略

关于优化是一项很大的内容。

2018-07-17

Android官方开发文档Training系列课程中文版：布局性能优化之ListView的优化

原文地址：http://android.xsoftlab.net/training/improving-layouts/smooth-scrolling.html 想要让ListView滑动流畅的关键所在是减轻主线程的负担。要确保任何的磁盘访问、网络访问、或者SQL访问都是在单独的线程中执行的。如果要测试APP的状态，可以开启StrictMode。使用后台线程使用工作线程可以使UI线程将所有的注意力都集中在UI的绘制上。在很多情况下，使用AsyncTask所提供的功能就可以在工作线程中处理耗时任务。AsyncTask会自动的将execute()发起的请求排队，并依次执行。这意味着你不要自己创建线程池。在下面的示例代码中，AsyncTask被用来加载一张图像，并在加载结束后自动的将其渲染到UI上。它还在图像加载时展示了一个旋转的进度条。 // Using an AsyncTask to load the slow images in a background thread new AsyncTask<ViewHolder, Void, Bitmap>() { private ViewHolder v; @Override protected Bitmap doInBackground(ViewHolder... params) { v = params[0]; return mFakeImageLoader.getImage(); } @Override protected void onPostExecute(Bitmap result) { super.onPostExecute(result); if (v.position == position) { // If this item hasn't been recycled already, hide the // progress and set and show the image v.progress.setVisibility(View.GONE); v.icon.setVisibility(View.VISIBLE); v.icon.setImageBitmap(result); } } }.execute(holder); 从Android 3.0开始，AsyncTask提供了一项新特性：可以将任务运行在多核处理器上。你可以使用executeOnExecutor()方法发起执行请求，这样多个请求就可以同时进行，同时进行的任务数量取决于CPU的核心数量。使用View Holder持有View对象在滑动ListView时，代码可能会频繁的调用findViewById()，这会降低性能。就算是Adapter将已经加载过的View返回，但是在复用时还是需要去查询这些View来更新它们。杜绝重复使用findViewById()的方法就是使用”View Holder”设计模式。 ViewHolder对象将每个View组件存储于布局容器的tag属性内，所以你可以快速访问它们而不需要每次都去查询。首先，你需要创建一个类来持有已加载的View： static class ViewHolder { TextView text; TextView timestamp; ImageView icon; ProgressBar progress; int position; } 然后对ViewHolder的成员属性赋值，然后将其存放在布局容器内： ViewHolder holder = new ViewHolder(); holder.icon = (ImageView) convertView.findViewById(R.id.listitem_image); holder.text = (TextView) convertView.findViewById(R.id.listitem_text); holder.timestamp = (TextView) convertView.findViewById(R.id.listitem_timestamp); holder.progress = (ProgressBar) convertView.findViewById(R.id.progress_spinner); convertView.setTag(holder); 那么现在就可以很方便的对这些View组件进行访问，而不再需要对它们单独进行查询，如此便可以节省出宝贵的CPU资源。

2016-09-20

Android官方开发文档Training系列课程中文版：布局性能优化之布局层级优化

优化布局层级有一个常见的误解就是使用基本的布局结构会使布局更高效。然而却不是这样的，每一个控件、布局容器都需要执行初始化、排布、绘制等过程。

2016-09-12

调问更新 11.7~11.14：矩阵题型优化 + 1 项功能新增 + 3 项功能优化 + 3 项 BugFix

docker 🔥 源码下载地址： https://gitee.com/wkeyuan/DWSurvey 🔥 官网地址：https://www.diaowen.net 调问上周对矩阵题型展示进行了集中优化

2025-11-17

优化技术专题-系统服务优化系列-这绝对是你的知识盲点，NUMA的为什么存在

NUMA的产生背景在NUMA架构出现前，CPU欢快的朝着频率越来越高的方向发展（纵向发展）。受到物理极限的挑战，又转为核数越来越多的方向发展（横向发展）。在一开始，内存控制器还在北桥中，所有CPU对内存的访问都要通过北桥来完成。此时所有CPU访问内存都是“一致的”，如下图所示：这样的架构称为UMA(Uniform Memory Access)，直译为“统一内存访问”，这样的架构对软件层面来说非常容易，总线模型保证所有的内存访问是一致的，即每个处理器核心共享相同的内存地址空间。但随着CPU核心数的增加，这样的架构难免遇到问题，比如对总线的带宽带来挑战、访问同一块内存的冲突问题。为了解决这些问题，有人搞出了NUMA。注意：北桥芯片（North Bridge）是主板芯片组中起主导作用的最重要的组成部分，也称为主桥（Host Bridge）。一般来说，芯片组的名称就是以北桥芯片的名称来命名的，例如：英特尔845E芯片组的北桥芯片是82845E，875P芯片组的北桥芯片是82875P等等。 NUMA构架细节通过“NUMA的产生背景”，让我们了解到了之前内存访问架构原则，与此相对的就是NUMA，NUMA 全称 Non-Uniform Memory Access，译为“非一致性内存访问”。这种构架下，不同的内存器件和CPU核心从属不同的Node，每个 Node 都有自己的集成内存控制器（IMC，Integrated Memory Controller）。在 Node 内部，架构类似SMP，使用IMC Bus进行不同核心间的通信；不同的 Node间通过QPI（Quick Path Interconnect）进行通信，如下图所示：一般来说，一个内存插槽对应一个Node。需要注意的一个特点是，QPI的延迟要高于IMC Bus，也就是说CPU访问内存有了远近（remote/local）之别，而且实验分析来看，这个差别非常明显。在Linux中，对于NUMA有以下几个需要注意的地方：默认情况下，内核不会将内存页面从一个 NUMA Node 迁移到另外一个 NUMA Node；但是有现成的工具可以实现将冷页面迁移到远程（Remote）的节点：NUMA Balancing；关于不同 NUMA Node 上内存页面迁移的规则，社区中有依然有不少争论。 NUMA详细分析非一致性内存架构(Non-uniform Memory Architecture)是为了解决传统的对称多处理(Symmetric Multi-processor)系统中的可扩展性问题而诞生的。在对称多处理系统中，处理器共享北桥中的内存控制器来达到共同访问外部内存和IO的目的，也就是说所有的处理器对内存和I/O的访问方式和开销都是相同的。在这种系统中，随着更多的处理器被添加到SMP系统中，总线的竞争将会越来越大，系统的性能也必将随之大打折扣。SMP系统的示意图如下：本地节点：对于某个节点中的所有CPU，此节点称为本地节点；(速度最快) 邻居节点：与本地节点相邻的节点称为邻居节点；（速度次之）远端节点：非本地节点或邻居节点的节点，称为远端节点。（速度最差）超立方体可以作为一种有效的拓扑来描述NUMA系统，它将系统中的节点数限制在2^C内，C是每个节点拥有的邻居节点数，如下图所示开销总结以C=3为例，则对于节点1而言，2,3,5则为邻居节点，4,6,7,8为远端节点，显然访问开销的关系为本地节点<邻居节点<远端节点。 NUMA案例分析 AMD Hyper-Transport 早期的SMP(对称多处理器系统) 只拥有一个位于北桥中的内存控制器，而如今更先进的做法是将内存控制器整合到CPU中去，这样每个CPU都拥有自己的内存控制器，不会相互之间产生竞争。最先采用这种做法的一批处理器就是AMD在2003年推出的AMD Opteron系列处理器，其结构如下图所示：每个CPU中都整合了一个内存控制器（IMC），并且CPU之间采用了一种Hyper-Transport的技术建立连接，这种连接可以使得CPU通过其他CPU来访问外部内存，当然访问开销要比访问本地内存更大。操作系统的支持为了支持NUMA架构，OS的设计必须将内存分布的特点考虑进去。举一个简单的例子，假如一个进程运行在一个给定的处理器中，那么为这个进程所分配的物理内存就应该是该处理器的本地内存，而不是外部内存。 OS还要注意避免将一个进程从一个节点给迁移到另一个节点。在一个普通的多处理系统中，OS就应该已经尝试不去在处理器之间迁移进程，因为这意味着一个处理器的cache中的相关内容都将被丢失。如果在某种情况下必须进行迁移，那么OS可以随意选择一个空闲的处理器。但是在NUMA系统中，可选择的新处理器将要受到一些限制，最重要的一点就是新处理器访问内存的开销不能比先前的处理器大，也就是说应该尽可能选择本地节点中的处理器。当找不到符合条件的处理器，OS才能选择其他类型的处理器。在这种较糟的情况下有两种选择：如果进程只是暂时性的被迁移出去，可以再将其迁移回更加合适的处理器；如果不是暂时性的，那么可以将该进程的内存拷贝到新处理器的内存中，这样就可以通过访问拷贝的内存来消除访问外部内存的开销，显然这是一种空间换时间的做法。 NUMA Node 操作 NUMA Node 分配有两个NUMA Node，每个节点管理16GB内存。 NUMA Node 绑定 Node 和 Node 之间进行通信的代价是不等的，同样是 Remote 节点，其代价可能不一样，这个信息在 node distances 中以一个矩阵的方式展现。我们可以将一个进程绑定在某个 CPU 或 NUMA Node 的内存上执行，如上图所示。 NUMA 状态

2021-04-29

支付宝 App 构建优化解析：通过安装包重排布优化 Android 端启动性能

前言本章节我们将围绕《支付宝 App 构建优化解析》另启新系列，细分拆解客户端在“代码管理”、“证书管理”、“版本管理”、“构建打包”等维度的具体实现方案展开讨论，带领大家进一步了解支付宝在 App

2018-12-18

RuoYi-Cloud 3.6.8 发布，更多细节优化

transmittable-thread-local到最新版本2.14.5 升级spring-boot到最新版本4.0.3 升级druid到最新版本1.2.28 升级pagehelper到最新版2.1.1 优化操作日志详细页面

2026-03-29

RuoYi-Vue 3.9.2 发布，更多细节优化

4.0.3 升级yauaa到最新版本8.1.0 升级oshi到最新版本6.10.0 升级druid到最新版本1.2.28 升级fastjson到最新版2.0.61 升级pagehelper到最新版2.1.1 优化操作日志详细页面

2026-03-25

RuoYi-Cloud 3.6.7 发布，更多细节优化

修复用户归属部门无法修改为空问题修复固定头部时出现的导航栏偏移问题修复v3时间控件between选择后清空报错问题修复comboReadDict属性下多个sheet出现的报错修复表单构建移除所有控件后切换路由回来空白问题优化布局设置显示

2025-12-22

RuoYi-Vue 3.9.1 发布，更多细节优化

2025-12-18

优化日志输出 | minRAG v0.1.3 发布

:<<十天手搓 minRAG, 操纵 DeepSeek 的幕后黑手> 下载体验:https://gitee.com/minrag/minrag/releases 界面预览更新: 优化日志输出

2025-11-14

优化日志输出 | gpress v1.1.7 发布

更新: 优化日志输出完善文档，注释

2025-11-14

Apache Doris 数据导入原理与性能优化

Apache Doris 本文将深入剖析 Doris 数据导入的核心原理，涵盖关键流程、组件、事务管理等，探讨影响导入性能的因素，并提供实用的优化方法和最佳实践，有助于用户选择合适的导入策略，优化导入性能

2025-10-11

资源下载

更多资源

优质分享App

近一个月的开发和优化，本站点的第一个app全新上线。该app采用极致压缩，本体才4.36MB。系统里面做了大量数据访问、缓存优化。方便用户在手机上查看文章。后续会推出HarmonyOS的适配版本。

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长，特征是大鼻子、头戴帽子、身穿背带裤，还留着胡子。与他的双胞胎兄弟路易基一起，长年担任任天堂的招牌角色。

Spring

Spring框架（Spring Framework）是由Rod Johnson于2002年提出的开源Java企业级应用框架，旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念，提供核心容器、应用上下文、数据访问集成等模块，支持整合Hibernate、Struts等第三方框架，其适用范围不仅限于服务器端开发，绝大多数Java应用均可从中受益。

Rocky Linux

Rocky Linux（中文名：洛基）是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版，作为CentOS稳定版停止维护后与RHEL（Red Hat Enterprise Linux）完全兼容的开源替代方案，由社区拥有并管理，支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性，采用模块化包装和SELinux安全架构，默认包含GNOME桌面环境及XFS文件系统，支持十年生命周期更新。