PHP 内存泄漏分析定位 - 研发管理 - ITeye资讯
jihong10102006
资讯频道 →
研发管理
阅读更多
2顶0踩
PHP 内存泄漏分析定位
2017-10-26 10:41 by 副主编 jihong10102006
评论(0)
有17006人浏览
php
内存泄露
声明：ITeye资讯文章的版权属于ITeye网站所有，严禁任何网站转载本文，否则必将追究法律责任！
引用来源：Gitbook前言本文开始撰写时我负责的项目需要用php开发一个通过 Socket 与服务端建立长连接后持续实时上报数据的常驻进程程序，在程序业务功能开发联调完毕后实际运行发送大量数据后发现内存增长非常迅速，在很短的时间内达到了 php 默认可用内存上限 128M ，并报错：Fatal error: Allowed memory size of X bytes exhausted (tried to allocate Y bytes)我第一反应是内存泄露了，但是不知道在哪。第二反应是无用的变量应该用完就 unset 掉，修改完毕后问题依旧。经过了几番周折终于解决了问题。就决定好好把类似情况整理一下，遂有此文，与诸君共勉。观察 PHP 程序内存使用情况php提提供了两个方法来获取当前程序的内存使用情况。memorygetusage()，这个函数的作用是获取目前PHP脚本所用的内存大小。memorygetpeak_usage()，这个函数的作用返回当前脚本到目前位置所占用的内存峰值，这样就可能获取到目前的脚本的内存需求情况。int memory_get_usage ([ bool $real_usage = false ] )
int memory_get_peak_usage ([ bool $real_usage = false ] )函数默认得到的是调用emalloc()占用的内存，如果设置参数为TRUE，则得到的是实际程序向系统申请的内存。因为 PHP 有自己的内存管理机制，所以有时候尽管内部已经释放了内存但并没有还给系统。linux 系统文件 /proc/{$pid}/status 会记录某个进程的运行状态，里面的 VmRSS 字段记录了该进程使用的常驻物理内存(Residence)，这个就是该进程实际占用的物理内存了，用这个数据比较靠谱，在程序里面提取这个值也很容易场景一：程序操作数据过大情景还原：一次性读取超过php可用内存上限的数据导致内存耗尽<?php
ini_set('memory_limit', '128M');
$string = str_pad('1', 128 * 1024 * 1024);
Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 134217729 bytes) in /Users/zouyi/php-oom/bigfile.php on line 3这是告诉我们程序运行时试图分配新内存时由于达到了PHP允许分配的内存上限而抛出致命错误，无法继续执行了，在 java 开发中一般称之为 OOM ( Out Of Memory ) 。PHP 配置内存上限是在php.ini中设置memory_limit，PHP 5.2 以前这个默认值是8M，PHP 5.2 的默认值是16M，在这之后的版本默认值都是128M。问题现象：特定数据处理时可复现，做任何 IO 操作都有可能遇到此类问题，比如：一次 mysql 查询返回大量数据、一次把大文件读取进程序等。解决方法：能用钱解决的问题都不是问题，如果程序要读大文件的机会不是很多，且上限可预期，那么通过ini_set('memory_limit', '1G');来设置一个更大的值或者memory_limit=-1。内存管够的话让程序一直跑也可以。如果程序需要考虑在小内存机器上也能正常使用，那就需要优化程序了。如下，代码复杂了很多。<?php
//php7 以下版本通过 composer 引入 paragonie/random_compat ，为了方便来生成一个随机名称的临时文件
require "vendor/autoload.php";
ini_set('memory_limit', '128M');
//生成临时文件存放大字符串
$fileName = 'tmp'.bin2hex(random_bytes(5)).'.txt';
touch($fileName);
for ( $i = 0; $i < 128; $i++ ) {
$string = str_pad('1', 1 * 1024 * 1024);
file_put_contents($fileName, $string, FILE_APPEND);
$handle = fopen($fileName, "r");
for ( $i = 0; $i <= filesize($fileName) / 1 * 1024 * 1024; $i++ )
//do something
$string = fread($handle, 1 * 1024 * 1024);
fclose($handle);
unlink($fileName);场景二：程序操作大数据时产生拷贝情景还原：执行过程中对大变量进行了复制，导致内存不够用。<?php
ini_set("memory_limit",'1M');
$string = str_pad('1', 1* 750 *1024);
$string2 = $string;
$string2 .= '1';
Fatal error: Allowed memory size of 1048576 bytes exhausted (tried to allocate 768001 bytes) in /Users/zouyi/php-oom/unset.php on line 8
Call Stack:
0.0004 235440 1. {main}() /Users/zouyi/php-oom/unset.php:0
zend_mm_heap corrupted问题现象：局部代码执行过程中占用内存翻倍。问题分析：php 是写时复制（Copy On Write），也就是说，当新变量被赋值时内存不发生变化，直到新变量的内容被操作时才会产生复制。解决方法：及早释放无用变量，或者以引用的形式操作原始数据。<?php
ini_set("memory_limit",'1M');
$string = str_pad('1', 1* 750 *1024);
$string2 = $string;
unset($string);
$string2 .= '1';
<?php
ini_set("memory_limit",'1M');
$string = str_pad('1', 1* 750 *1024);
$string2 = &$string;
$string2 .= '1';
unset($string2, $string);场景三：配置不合理系统资源耗尽情景还原：因配置不合理导致内存不够用，2G 内存机器上设置最大可以启动 100 个 php-fpm 子进程，但实际启动了 50 个 php-fpm 子进程后无法再启动更多进程问题现象：线上业务请求量小的时候不出现问题，请求量一旦很大后部分请求就会执行失败问题分析：一般为了安全方面考虑， php 限制表单请求的最大可提交的数量及大小等参数，post_max_size、max_file_uploads、upload_max_filesize、max_input_vars、max_input_nesting_level。 假设带宽足够，用户频繁的提交post_max_size = 8M数据到服务端，nginx 转发给 php-fpm 处理，那么每个 php-fpm 子进程除了自身占用的内存外，即使什么都不做也有可能多占用 8M 内存。解决方法：合理设置post_max_size、max_file_uploads、upload_max_filesize、max_input_vars、max_input_nesting_level等参数并调优 php-fpm 相关参数。$ php -i |grep memory
memory_limit => 1024M => 1024M //php脚本执行最大可使用内存
$php -i |grep max
max_execution_time => 0 => 0 //最大执行时间，脚本默认为0不限制，web请求默认30s
max_file_uploads => 20 => 20 //一个表单里最大上传文件数量
max_input_nesting_level => 64 => 64 //一个表单里数据最大数组深度层数
max_input_time => -1 => -1 //php从接收请求开始处理数据后的超时时间
max_input_vars => 1000 => 1000 //一个表单（包括get、post、cookie的所有数据）最多提交1000个字段
post_max_size => 8M => 8M //一次post请求最多提交8M数据
upload_max_filesize => 2M => 2M //一个可上传的文件最大不超过2M如果上传设置不合理那么出现大量内存被占用的情况也不奇怪，比如有些内网场景下需要 post 超大字符串post_max_size=200M，那么当从表单提交了 200M 数据到服务端， php 就会分配 200M 内存给这条数据，直到请求处理完毕释放内存。pm = dynamic //仅dynamic模式下以下参数生效
pm.max_children = 10 //最大子进程数
pm.start_servers = 3 //启动时启动子进程数
pm.min_spare_servers = 2 //最小空闲进程数，不够了启动更多进程
pm.max_spare_servers = 5 //最大空闲进程数，超过了结束一些进程
pm.max_requests = 500 //最大请求数，注意这个参数是一个php-fpm如果处理了500个请求后会自己重启一下，可以避免一些三方扩展的内存泄露问题一个 php-fpm 进程按 30MB 内存算，50 个 php-fpm 进程就需要 1500MB 内存，这里需要简单估算一下在负载最重的情况下所有 php-fpm 进程都启动后是否会把系统内存耗尽。$ulimit -a
-t: cpu time (seconds) unlimited
-f: file size (blocks) unlimited
-d: data seg size (kbytes) unlimited
-s: stack size (kbytes) 8192
-c: core file size (blocks) 0
-v: address space (kbytes) unlimited
-l: locked-in-memory size (kbytes) unlimited
-u: processes 1024
-n: file descriptors 1024这是我本地mac os的配置，文件描述符的设置是比较小的，一般生产环境配置要大得多。场景四：无用的数据未及时释放情景还原：这种问题从程序逻辑上不是问题，但是无用的数据大量占用内存导致资源不够用，应该有针对性的做代码优化。Laravel开发中用于监听数据库操作时有如下代码: DB::listen(function ($query) {
// $query->sql
// $query->bindings
// $query->time
});启用数据库监听后，每当有 SQL 执行时会 new 一个 QueryExecuted 对象并传入匿名函数以便后续操作，对于执行完毕就结束进程释放资源的php程序来说没有什么问题，而如果是一个常驻进程的程序，程序每执行一条 SQL 内存中就会增加一个 QueryExecuted 对象，程序不结束内存就会始终增长。问题现象：程序运行期间内存逐渐增长，程序结束后内存正常释放。问题分析：此类问题不易察觉，定位困难，尤其是有些框架封装好的方法，要明确其适用场景。解决方法：本例中要通过DB::listen方法获取所有执行的 SQL 语句记录并写入日志，但此方法存在内存泄露问题，在开发环境下无所谓，在生产环境下则应停用，改用其他途径获取执行的 SQL 语句并写日志。深入了解1. 名词解释内存泄漏（Memory Leak）：是程序在管理内存分配过程中未能正确的释放不再使用的内存导致资源被大量占用的一种问题。在面向对象编程时，造成内存泄露的原因常常是对象在内存中存储但是运行中的代码却无法访问他。由于产生类似问题的情况很多，所以只能从源码上入手分析定位并解决。垃圾回收（Garbage Collection，简称GC）：是一种自动内存管理的形式，GC程序检查并处理程序中那些已经分配出去但却不再被对象使用的内存。最早的GC是1959年前后John McCarthy发明的，用来简化在Lisp中手动控制内存管理。 PHP的内核中已自带内存管理的功能，一般应用场景下，不易出现内存泄露。追踪法（Tracing）：从某个根对象开始追踪，检查哪些对象可访问，那么其他的（不可访问）就是垃圾。引用计数法（reference count）：每个对象都一个数字用来标示被引用的次数。引用次数为0的可以回收。当对一个对象的引用创建时他的引用计数就会增加，引用销毁时计数减少。引用计数法可以保证对象一旦不被引用时第一时间销毁。但是引用计数有一些缺陷：1.循环引用，2.引用计数需要申请更多内存，3.对速度有影响，4.需要保证原子性，5.不是实时的2. php 内存管理引用在 PHP 5.2 以前, PHP 使用引用计数(Reference count)来做资源管理, 当一个 zval 的引用计数为 0 的时候, 它就会被释放. 虽然存在循环引用(Cycle reference), 但这样的设计对于开发 Web 脚本来说, 没什么问题, 因为 Web 脚本的特点和它追求的目标就是执行时间短, 不会长期运行. 对于循环引用造成的资源泄露, 会在请求结束时释放掉. 也就是说, 请求结束时释放资源, 是一种部补救措施( backup ).然而, 随着 PHP 被越来越多的人使用, 就有很多人在一些后台脚本使用 PHP , 这些脚本的特点是长期运行, 如果存在循环引用, 导致引用计数无法及时释放不用的资源, 则这个脚本最终会内存耗尽退出.所以在 PHP 5.3 以后, 我们引入了 GC .—— 摘自鸟哥博客文章《请手动释放你的资源》在 PHP 5.3 以后引入了同步周期回收算法(Concurrent Cycle Collection)来处理内存泄露问题，代价是对性能有一定影响，不过一般 web 脚本应用程序影响很小。PHP的垃圾回收机制是默认打开的，php.ini 可以设置zend.enable_gc=0来关闭。也能通过分别调用gcenable() 和 gcdisable()函数来打开和关闭垃圾回收机制。虽然垃圾回收让php开发者在内存管理上无需担心了，但也有极端的反例：php界著名的包管理工具composer曾因加入一行gc_disable();性能得到极大提升。传送门引用计数基本知识回收周期(Collecting Cycles)上面两个链接是php官方手册中的内存管理、GC相关知识讲解，图文并茂，这里不再赘述。3. php-fpm 内存泄露问题在一台常见的 nginx + php-fpm 的服务器上：nginx 服务器 fork 出 n 个子进程（worker）， php-fpm 管理器 fork 出 n 个子进程。当有用户请求， nginx 的一个 worker 接收请求，并将请求抛到 socket 中。php-fpm 空闲的子进程监听到 socket 中有请求，接收并处理请求。一个 php-fpm 的生命周期大致是这样的：模块初始化（MINIT）-> 请求初始化（RINIT）-> 请求处理 -> 请求结束（RSHUTDOWN） -> 请求初始化（RINIT）-> 请求处理 -> 请求结束（RSHUTDOWN）……. 请求初始化（RINIT）-> 请求处理 -> 请求结束（RSHUTDOWN）-> 模块关闭（MSHUTDOWN）。在请求初始化（RINIT）-> 请求处理 -> 请求结束（RSHUTDOWN）这个“请求处理”过程是： php 读取相应的 php 文件，对其进行词法分析，生成 opcode ， zend 虚拟机执行 opcode 。php 在每次请求结束后自动释放内存，有效避免了常见场景下内存泄露的问题，然而实际环境中因某些扩展的内存管理没有做好或者 php 代码中出现循环引用导致未能正常释放不用的资源。在 php-fpm 配置文件中，将pm.max_requests这个参数设置小一点。这个参数的含义是：一个 php-fpm 子进程最多处理pm.max_requests个用户请求后，就会被销毁。当一个 php-fpm 进程被销毁后，它所占用的所有内存都会被回收。4. 常驻进程内存泄露问题Valgrind 包括如下一些工具：Memcheck。这是 valgrind 应用最广泛的工具，一个重量级的内存检查器，能够发现开发中绝大多数内存错误使用情况，比如：使用未初始化的内存，使用已经释放了的内存，内存访问越界等。Callgrind。它主要用来检查程序中函数调用过程中出现的问题。Cachegrind。它主要用来检查程序中缓存使用出现的问题。Helgrind。它主要用来检查多线程程序中出现的竞争问题。Massif。它主要用来检查程序中堆栈使用中出现的问题。Extension。可以利用core提供的功能，自己编写特定的内存调试工具。Memcheck 对调试 C/C++ 程序的内存泄露很有帮助，它的机制是在系统 alloc/free 等函数调用上加计数。 php 程序的内存泄露，是由于一些循环引用，或者 gc 的逻辑错误, valgrind 无法探测，因此需要在检测时需要关闭 php 自带的内存管理。$ export USE_ZEND_ALLOC=0 # 设置环境变量关闭内存管理
$ valgrind --tool=memcheck --num-callers=30 --log-file=php.log /Users/zouyi/Downloads/php-5.6.31/sapi/cli/php leak.php通过命令行执行 valgrind 分析可能有内存泄露的文件引用==12075== Memcheck, a memory error detector==12075== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.==12075== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info==12075== Command: /Users/zouyi/Downloads/php-5.6.31/sapi/cli/php leak.php==12075== Parent PID: 42043==12075====12075== Syscall param msg->desc.port.name points to uninitialised byte(s)==12075== at 0x10121F34A: mach_msg_trap (in /usr/lib/system/libsystem_kernel.dylib)==12075== by 0x10121E796: mach_msg (in /usr/lib/system/libsystem_kernel.dylib)==12075== by 0x101218485: task_set_special_port (in /usr/lib/system/libsystem_kernel.dylib)==12075== by 0x1013B410E: _os_trace_create_debug_control_port (in /usr/lib/system/libsystem_trace.dylib)==12075== by 0x1013B4458: _libtrace_init (in /usr/lib/system/libsystem_trace.dylib)==12075== by 0x100DF09DF: libSystem_initializer (in /usr/lib/libSystem.B.dylib)==12075== by 0x100C37A1A: ImageLoaderMachO::doModInitFunctions(ImageLoader::LinkContext const&) (in /usr/lib/dyld)==12075== by 0x100C37C1D: ImageLoaderMachO::doInitialization(ImageLoader::LinkContext const&) (in /usr/lib/dyld)==12075== by 0x100C334A9: ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, char const*, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) (in /usr/lib/dyld)==12075== by 0x100C33440: ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, char const*, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) (in /usr/lib/dyld)==12075== by 0x100C32523: ImageLoader::processInitializers(ImageLoader::LinkContext const&, unsigned int, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) (in /usr/lib/dyld)==12075== by 0x100C325B8: ImageLoader::runInitializers(ImageLoader::LinkContext const&, ImageLoader::InitializerTimingList&) (in /usr/lib/dyld)==12075== by 0x100C24433: dyld::initializeMainExecutable() (in /usr/lib/dyld)==12075== by 0x100C288C5: dyld::_main(macho_header const*, unsigned long, int, char const**, char const**, char const**, unsigned long*) (in /usr/lib/dyld)==12075== by 0x100C23248: dyldbootstrap::start(macho_header const*, int, char const**, long, macho_header const*, unsigned long*) (in /usr/lib/dyld)==12075== by 0x100C23035: _dyld_start (in /usr/lib/dyld)==12075== by 0x1: ???==12075== by 0x1054AC862: ???==12075== by 0x1054AC891: ???==12075== Address 0x1054aa98c is on thread 1's stack==12075== in frame #2, created by task_set_special_port (???:)==12075==--12075-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option--12075-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option (repeated 2 times)--12075-- UNKNOWN mach_msg unhandled MACH_SEND_TRAILER option (repeated 4 times)==12075====12075== HEAP SUMMARY:==12075== in use at exit: 125,805 bytes in 185 blocks==12075== total heap usage: 14,686 allocs, 14,501 frees, 3,261,322 bytes allocated==12075====12075== LEAK SUMMARY:==12075== definitely lost: 3 bytes in 1 blocks==12075== indirectly lost: 0 bytes in 0 blocks==12075== possibly lost: 72 bytes in 3 blocks==12075== still reachable: 107,582 bytes in 23 blocks==12075== suppressed: 18,148 bytes in 158 blocks==12075== Rerun with --leak-check=full to see details of leaked memory==12075====12075== For counts of detected and suppressed errors, rerun with: -v==12075== Use --track-origins=yes to see where uninitialised values come from==12075== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 1 from 1)引用definitely lost: 肯定内存泄露indirectly lost: 非直接内存泄露possibly lost: 可能发生内存泄露still reachable: 仍然可访问的内存suppressed: 外部造成的内存泄露Callgrind 配合 php 扩展 xdebug 输出的 profile 分析日志文件可以分析程序运行期间各个函数调用时占用的内存、 CPU 占用情况。总结遇到了内存泄露时先观察是程序本身内存不足还是外部资源导致，然后搞清楚程序运行中用到了哪些资源：写入磁盘日志、连接数据库 SQL 查询、发送 Curl 请求、 Socket 通信等， I/O 操作必然会用到内存，如果这些地方都没有发生明显的内存泄露，检查哪里处理大量数据没有及时释放资源，如果是 php 5.3 以下版本还需考虑循环引用的问题。多了解一些 Linux 下的分析辅助工具，解决问题时可以事半功倍。最后宣传一下穿云团队今年最新开源的应用透明链路追踪工具 Molten：https://github.com/chuan-yun/Molten。安装好php扩展后就能帮你实时收集程序的 curl,pdo,mysqli,redis,mongodb,memcached 等请求的数据，可以很方便的与 zipkin 集成。参考资料http://php.net/manual/zh/features.gc.phphttp://www.php-internals.com/book/?p=chapt06/06-07-memory-leakshttp://www.programering.com/a/MDN5UjMwATk.htmlhttps://stackoverflow.com/questions/20458136/using-valgrind-to-debug-a-php-cli-segmentation-faulthttp://www.laruence.com/2013/08/14/2899.htmlhttps://mengkang.net/873.html
来自: GitChat
分享到：
2 顶0 踩
评论 共 0 条 请登录后发表评论
发表评论
您还没有登录,请您登录后再发表评论
相关推荐
7 php 内存泄漏_PHP内存泄漏分析定位
说明：本文来自作者邹毅在GitChat上分享「PHP 内存泄漏分析定位」目录场景一 程序操作数据过大场景二 程序操作大数据时产生拷贝场景三 配置不合理系统资源耗尽场景四 无用的数据未及时释放深入了解php内存管理...
7 php 内存泄漏_PHP 内存泄漏分析定位（转载）
目录场景一 程序操作数据过大场景二 程序操作大数据时产生拷贝场景三 配置不合理系统资源耗尽场景四 无用的数据未及时释放深入了解php内存管理php-fpm内存泄露问题常驻进程内存泄露问题前言本文开始撰写时我负责的...
7 php 内存泄漏_PHP 内存泄漏分析定位
引用前言本文开始撰写时我负责的项目需要用php开发一个通过 Socket 与服务端建立长连接后持续实时上报数据的常驻进程程序，在程序业务功能开发联调完毕后实际运行发送大量数据后发现内存增长非常迅速，在很短的时间...
PHP 常驻内存泄漏分析定位
在使用常驻内存框架需要注意什么？ 内存释放 数据污染 资源释放 静态变量保存的对象不会被释放，需要手动管理 禁止使用exit和die 禁止使用sleep时间长的函数，防止导致Worker进程退出 ...
7 php 内存泄漏_定位分析内存泄漏的原因和后果
内部泄漏错误代码：Fatal error: Allowed memory size of X bytes exhausted (tried to allocate Y bytes)观察php程序内存使用情况php提提供了两个方法来获取当前程序的内存使用情况。memorygetusage()，这个函数的...
排查php内存泄露
这个就是传说中的内存泄露，所谓内存泄露，是指进程在运行过程中，内存占用率逐步上升而不释放，导致系统可用内存越来越少的情况 严格上说，这个也不算致命错误，“内存泄露”只对长期运行的程序有威胁，对单一任务...
java分析内存泄露工具_Eclipse Memory Analyzer（Java内存泄漏分析工具）
如内存泄漏，遇到这样的问题对于一个经验尚浅的开发人员来说难度非常大，好的一点是JVM 能够记录下问题发生时系统的部分运行状态，并将其存储在堆转储 (Heap Dump) 文件中，从而为我们分析和诊断问题提供了重要的...
php内存泄露的原因,关于PHP内存泄漏的问题
通常情况下PHP是很少发生内存泄漏这种问题的，只有在PHP内存耗尽了才会导致内存泄漏的问题出现(一般这种情况下多数都是自己代码写的有问题或者第三方请求导致的)。查看内存占用一般有三个点需要注意：RSS - Resident...
Java 内存指令分析和内存泄漏的定位
今天讲一下怎么对内存进行简单的分析和排查。 Windows环境下 windows 环境下我们可以用JDK自带的两个工具jconsole 和jvisualvm进行简单的分析，这两个工具都在JDK的bin目录下 下面简单介绍一下如何使用，双击打开...
php内存泄漏的后果,记一次php内存泄漏的排查经过
在开发环境是没有问题的，但是上线后却发现运行了几分钟后，进程就没有异常报错的退出了，没有触发任何错误日志，让我一脸懵逼(黑人问号脸)问题分析确定问题首先在每次循环里加入计数器，并且使用memory_get_u...
php 内存泄露检测工具,PHP 中如何定位内存泄露的代码所在行呢？
15207 天前php 碰到内存“泄露”问题，有几个方面1. “全局变量” 或者 “常驻依赖注入容器对象” 的膨胀导致内存不够，比如 orm 中 EntityManager 没有及时 clear 追踪的不再被使用的数据库实体对象。2. 代码逻辑...
Android studio内存泄露分析工具使用
什么是内存泄漏 Android虚拟机的垃圾回收采用的是根搜索算法。GC会从根节点（GC Roots）开始对heap进行遍历。到最后，部分没有直接或者间接引用到GC Roots的就是需要回收的垃圾，会被GC回收掉。而内存泄漏出现的...
PHP内存泄露分析
Socket 与服务端建立长连接后持续实时上报数据的常驻进程程序，在程序业务功能开发联调完毕后实际运行发送大量数据后发现内存增长非常迅速，在很短的时间内达到了 php 默认可用内存上限 128M ，并报错： 代码 Fatal...
mat 内存分析 Linux,使用MAT分析内存泄露
对于大型服务端应用程序来说，有些内存泄露问题很难在测试阶段发现，此时就需要分析JVM Heap Dump文件来找出问题。随着单机内存越来越大，应用heap也开得越来越大，动辄十几G的Dump也不足为奇了。要快速分析，快速...
锂电池基础知识介绍.pdf
动力锂电池及BMS系统资料
操作系统与设备驱动程序的安装-实验报告.doc
操作系统与设备驱动程序的安装-实验报告.doc
Last Loaded proteus.DBK
Last Loaded proteus.DBK
40个思维模型.pptx
思维模型是你大脑中做决策的工具箱，你的工具箱越多，你就越能快速做出最正确的决策。
分享40个工作中常用的思维模型，主要分为学习力、思考力、创造力、设计力、共情力、故事力、领导力、整合力，可以帮助你由浅入深地对不同方向的思维模型进行学习。
边学边用，前期刻意学习，逐渐成为习惯，逼迫自己进行深度思考。
操作系统pcb的组织及维护实验.doc
操作系统pcb的组织及维护实验.doc
绿色渐变大气商务科技公司响应式模板-精品 漂亮 css3动画 html5服务 设计 ui设计 平面设计 菜单 简洁 清爽 宽屏
绿色渐变大气商务科技公司响应式模板_绿色 渐变 精品 漂亮 大气 商务 科技 css3动画 ft5 html5 互联网 集团 企业 官网 服务 设计 ui设计 平面设计 菜单 简洁 清爽 宽屏 it科技 商业.rar
ITeye首页
资讯
精华
论坛
问答
博客
专栏
群组
下载
资源
搜索
您还未登录!
登录
广告服务
ITeye黑板报
联系我们
友情链接
2003-2022 ITeye.com. [ 京ICP备19004658 京公网安备11010502030278 ]
北京创新乐知网络技术有限公司 版权所有
Global site tag (gtag.js) - Google Analytics