手动更新数据库时内存占用过大
phoenixxie0 opened this issue · 18 comments
在UNRAID上手动设置了-m 384M限制内存使用，但是手动更新数据库的时候，会导致内存占用过大，然后会导致更新失败。
如果不用-m设置内存限制，能更新成功，但是写入数据库瞬间，可能会超过512M的内存。
限制为512M，依然占用满，且更新失败.
限制为768M，依然占用满，且更新失败.
直到把内存设置到960M才能更新成功。
能提供一下epg源，我测试一下吗？我之前是分batch插入的，后面改回来了。
奇怪，我用的也是你这三个源，倒是一切正常，而且我的还是2G渣渣主机。
而且你这个erw源还不是7天回放，按道理不怎么占用内存吧。
不知道是不是 gitee 限制访问 xml 文件，导致程序异常了，建议用 e.xml.gz ，现在还不会限制。
我还是改回之前分批插入了，换了一种实现，之前觉得实现得太不优雅，就给删除了。
过两天更新，到时候你再帮忙测试一下。我这边没UNRAID设备。
我看了后台的进程，现在的实现方式好像是并发执行。我现在一个个源来测试，是哪个发生了问题，看看情况先.
三条源，每一个都单独进行了测试，如果设置了内存限制256M,都会卡死。
更新分批插入了，你试试还会不会报错。
设置128M内存无法更新，设置192M内存OK。
但是现在又出现无法保存配置的情况，更新docker之后，配置无法保存了，是否更换了配置保存的文件
是的，新版本改用 config.json 来存配置文件了。
内存这个，你可以尝试修改 update.php 第 252 行 if (count($currentChannelProgrammes) >= 50)，看看改小一点能不能降低内存占用。
不过我猜是后面生成 xml 文件的时候内存占用比较高，因为最后还是要读进来才能生成 .xml.gz 文件，没办法分批。
亲测是PHP脚本导入SQLite时转码和导入时间过长，我在Arm平台上测试需要峰值600MB内存，amd64平台需要300~400MB不等，且SQLite仓库不支持高并发，我的那个仓库mxd's EPG的代码就是基于老张的改的，他原版就是SQLite数据库，api那边请求一高就锁库，所以我才改为MySQL+Redis。
以下是个AI的答复，仅供参考，比我测试的数据还要离谱些
如果需要一个粗略的最大值估算，考虑到可能的缓存、批量操作和PHP脚本的开销，可能需要预备高达500MB到1GB的内存。然而，这个数字需要根据实际情况进行测试和调整。如果需要更精确的内存使用估算，可以在PHP脚本中使用memory_get_usage()函数来监测内存使用情况，并根据测试结果进行优化 。
亲测是PHP脚本导入SQLite时转码和导入时间过长，我在
Arm平台上测试需要峰值600MB内存，amd64平台需要300~400MB不等，且SQLite仓库不支持高并发，我的那个仓库mxd's EPG的代码就是基于老张的改的，他原版就是SQLite数据库，api那边请求一高就锁库，所以我才改为MySQL+Redis。以下是个AI的答复，仅供参考，比我测试的数据还要离谱些
如果需要一个粗略的最大值估算，考虑到可能的缓存、批量操作和PHP脚本的开销，可能需要预备高达500MB到1GB的内存。然而，这个数字需要根据实际情况进行测试和调整。如果需要更精确的内存使用估算，可以在PHP脚本中使用
memory_get_usage()函数来监测内存使用情况，并根据测试结果进行优化 。
奇怪，我这边也测试过，在 arm 跟 amd64 平台上，这几个源最大消耗内存都是 100~200M。
SQLite 的话，可能因为我这边只有几个朋友在用，2G4M 的小水管也绰绰有余了。
如果像你这样，打算提供给大家用，还是得 MySQL + Redis。
亲测是PHP脚本导入SQLite时转码和导入时间过长，我在
Arm平台上测试需要峰值600MB内存，amd64平台需要300~400MB不等，且SQLite仓库不支持高并发，我的那个仓库mxd's EPG的代码就是基于老张的改的，他原版就是SQLite数据库，api那边请求一高就锁库，所以我才改为MySQL+Redis。
以下是个AI的答复，仅供参考，比我测试的数据还要离谱些
如果需要一个粗略的最大值估算，考虑到可能的缓存、批量操作和PHP脚本的开销，可能需要预备高达500MB到1GB的内存。然而，这个数字需要根据实际情况进行测试和调整。如果需要更精确的内存使用估算，可以在PHP脚本中使用memory_get_usage()函数来监测内存使用情况，并根据测试结果进行优化 。奇怪，我这边也测试过，在
arm跟amd64平台上，这几个源最大消耗内存都是 100~200M。SQLite的话，可能因为我这边只有几个朋友在用，2G4M 的小水管也绰绰有余了。 如果像你这样，打算提供给大家用，还是得MySQL+Redis。
如果你的主机设置有swap，那么docker会使用它，导致内存估计并不准确
亲测是PHP脚本导入SQLite时转码和导入时间过长，我在
Arm平台上测试需要峰值600MB内存，amd64平台需要300~400MB不等，且SQLite仓库不支持高并发，我的那个仓库mxd's EPG的代码就是基于老张的改的，他原版就是SQLite数据库，api那边请求一高就锁库，所以我才改为MySQL+Redis。
以下是个AI的答复，仅供参考，比我测试的数据还要离谱些
如果需要一个粗略的最大值估算，考虑到可能的缓存、批量操作和PHP脚本的开销，可能需要预备高达500MB到1GB的内存。然而，这个数字需要根据实际情况进行测试和调整。如果需要更精确的内存使用估算，可以在PHP脚本中使用memory_get_usage()函数来监测内存使用情况，并根据测试结果进行优化 。奇怪，我这边也测试过，在
arm跟amd64平台上，这几个源最大消耗内存都是 100~200M。SQLite的话，可能因为我这边只有几个朋友在用，2G4M 的小水管也绰绰有余了。 如果像你这样，打算提供给大家用，还是得MySQL+Redis。如果你的主机设置有swap，那么docker会使用它，导致内存估计并不准确
我没有设置swap哎
亲测是PHP脚本导入SQLite时转码和导入时间过长，我在
Arm平台上测试需要峰值600MB内存，amd64平台需要300~400MB不等，且SQLite仓库不支持高并发，我的那个仓库mxd's EPG的代码就是基于老张的改的，他原版就是SQLite数据库，api那边请求一高就锁库，所以我才改为MySQL+Redis。以下是个AI的答复，仅供参考，比我测试的数据还要离谱些
如果需要一个粗略的最大值估算，考虑到可能的缓存、批量操作和PHP脚本的开销，可能需要预备高达500MB到1GB的内存。然而，这个数字需要根据实际情况进行测试和调整。如果需要更精确的内存使用估算，可以在PHP脚本中使用
memory_get_usage()函数来监测内存使用情况，并根据测试结果进行优化 。
今天测试了，主要内存开销是生成 xml 文件的时候，如果不选预告数据，选择全部数据的话，分分钟飙到 700 多兆。
改用 XMLWriter ，内存降到 100 兆以内了。生成速度还更快。
亲测是PHP脚本导入SQLite时转码和导入时间过长，我在
Arm平台上测试需要峰值600MB内存，amd64平台需要300~400MB不等，且SQLite仓库不支持高并发，我的那个仓库mxd's EPG的代码就是基于老张的改的，他原版就是SQLite数据库，api那边请求一高就锁库，所以我才改为MySQL+Redis。
以下是个AI的答复，仅供参考，比我测试的数据还要离谱些
如果需要一个粗略的最大值估算，考虑到可能的缓存、批量操作和PHP脚本的开销，可能需要预备高达500MB到1GB的内存。然而，这个数字需要根据实际情况进行测试和调整。如果需要更精确的内存使用估算，可以在PHP脚本中使用memory_get_usage()函数来监测内存使用情况，并根据测试结果进行优化 。奇怪，我这边也测试过，在
arm跟amd64平台上，这几个源最大消耗内存都是 100~200M。SQLite的话，可能因为我这边只有几个朋友在用，2G4M 的小水管也绰绰有余了。 如果像你这样，打算提供给大家用，还是得MySQL+Redis。如果你的主机设置有swap，那么docker会使用它，导致内存估计并不准确
嗯嗯，应该是这个原因。
换了一个方案，明天发布之后帮忙测试一下 :)
更新了，有空帮忙测试一下。
在我这边 amd64 跟 arm64 内存占用都降到 100M 以内了。
更新了，有空帮忙测试一下。 在我这边 amd64 跟 arm64 内存占用都降到 100M 以内了。
实测amd64121MB，arm64109MB，再次感谢 @TakcC ，向您致敬
更新了，有空帮忙测试一下。 在我这边 amd64 跟 arm64 内存占用都降到 100M 以内了。
实测
amd64121MB，arm64109MB，再次感谢 @TakcC ，向您致敬
:)