搜索功能上了solr之后频繁503，这个bug修复了。

最开始发现，连续搜索不同的项目，有时会出现空白页，打开浏览器控制台，发现是503代码，服务器响应问题，准确说是单独部署在jetty上的solr服务的稳定性问题。本地测试的时候没事，但看服务端solr日志，却发现每时每刻都在重启jetty服务中。通过top查看资源，发现solr服务每隔一段时间都会有高达200%左右的CPU，而内存一度占了700M左右，这可一点也不轻量（或者说这确实是资源密集型服务233333😂。

问了AI，给出了很多可能的理由，一度怀疑是solr的配置文件弄错导致的无限重启（毕竟solr的配置也算是目前见识过的最复杂的了233333。后来在日志文件夹看到了一个gc.log，垃圾回收也确实是AI给出的一个可能原因，于是打开看了一下，确实在频繁的清理。这时候才想到，服务器的剩余内存只剩下100多兆了。

然后想办法压缩solr的占用内存。才注意到初始设置都要512M起步，但实际占用经常高达700多，已经比得上主服务tomcat的内存了。既然初始设置都已引发了频繁GC，降低堆大小可能无济于事，于是尝试了关闭不必要的字段索引、减少查询缓存，但几乎没什么变化。

然后想，既然solr单独部署在Jetty下需要jvm额外分配完整的虚拟空间，是否将它放到tomcat下会好一点呢？很遗憾没能验证，由于solr版本迭代太多，能找到的案例大多是tomcat下单独配置solr、而不是兼用其他服务，时间问题作罢。AI说Jetty本身对Solr有一定优化，这也打消了继续将它跟tomcat整合的念头。

另一个问题是solr的权限配置：其select服务必然是要对外的，但是update/admin等服务、管理页面必然要设置权限验证，研究了一圈发现有点复杂，暂时搁置。

于是在想，solr封装lucene到底带来了什么好处？AI的回答重点在分布式集群、大数据高并发应对、封装服务，而solr本身的特点就是尽可能多的占用内存（这也算是一个优点？2333333）。这些对我来说似乎没什么必要，那么不如舍弃solr，直接通过maven集成Lucene。经过摸索和实现，其搜索效果几乎没什么改变，速度没什么差异，稳定性更是杠杠的，而tomcat的内存也从700多M降到了500多M（有谁能告诉我，为什么单单是去除solrJ、换成Lucene就能将tomcat内存占用减小200M？

然后我愉快地systemctl stop solr.service & systemctl disable solr.service、关闭8983端口、并取消了nginx中的solr代理，通过top查看资源，可用内存回到了1G左右。

于是又想到了这篇文章：未必要用scrawl-canvas，果然适合自己的才是好的，以上。