Elasticsearch未公开客户端. Tomcat关闭后的活动线程.内存使用有何影响? [英] Elasticsearch unclosed client. Live threads after Tomcat shutdown. Memory usage impact?

问题描述

我正在使用Elasticsearch 1.5.1和Tomcat 7.在通过Spring Framework服务器启动期间，Web应用程序将TCP client实例创建为Singleton.

I am using Elasticsearch 1.5.1 and Tomcat 7. Web application creates a TCP client instance as Singleton during server startup through Spring Framework.

仅注意到在服务器关闭期间我无法关闭客户端. 通过对诸如VisualVm, JConsole, MAT in Eclipse之类的各种工具的分析，很明显，即使在服务器(tomcat)关闭之后，elasticsearch客户端创建的线程仍然可以使用.

Just noticed that I failed to close the client during server shutdown. Through analysis on various tools like VisualVm, JConsole, MAT in Eclipse, it is evident that threads created by the elasticsearch client are live even after server(tomcat) shutdown.

注意:在通过Context Listener destroy方法引入client.close()之后，线程被优雅地杀死.

Note: after introducing client.close() via Context Listener destroy methods, the threads are killed gracefully.

但是我的查询是

1. 如何检查这些活动线程占用的内存?
2. 此线程对内存泄漏有影响吗?

我们在PROD中几乎没有Out of memory:Perm gen错误.这可能是一个原因，但I would like to measure and provide stats for this.

We have got few Out of memory:Perm gen errors in PROD. This might be a reason but still I would like to measure and provide stats for this.

请提供任何建议/帮助.

Any suggestions/help please.

推荐答案

通常，客户端在与其通信的服务不同的进程中运行.例如，我可以在Web浏览器中打开网页，然后关闭Web服务器，客户端将保持打开状态.

Typically clients run in a different process than the services they communicate with. For example, I can open a web page in a web browser, and then shutdown the webserver, and the client will remain open.

这与TCP/IP的基础设计选择有关.在细节上，大多数情况下，客户端仅在下一次向服务器请求时才检测到服务器已消失. (通常来说)，它不会连续轮询服务器以查看其是否还处于活动状态，也不会在关闭服务器时发送请断开连接"消息.

This has to do with the underlying design choices of TCP/IP. Glossing over the details, under most cases a client only detects it's server is gone during the next request to the server. (Again generally speaking) it does not continually poll the server to see if it is alive, nor does the server generally send a "please disconnect" message on shutting down.

客户端通常不轮询服务器的原因是因为它允许服务器处理更多客户端.使用轮询方法时，服务器受到运行的客户端数量的限制，但是如果没有轮询方法，则服务器会受到活动通信的客户端数量的限制.这样一来，由于许多正在运行的客户端没有进行主动通信，因此它可以支持更多的客户端.

The reason that clients don't generally poll servers is because it allows the server to handle more clients. With a polling approach, the server is limited by the number of clients running, but without a polling approach, it is limited by the number of clients actively communicating. This allows it to support more clients because many of the running clients aren't actively communicating.

服务器通常不发送我正在关闭"消息的原因是因为服务器多次失控地停机(断电，操作系统崩溃，火灾，短路等)，这意味着协议如果服务器以不受控制的方式关闭，则需要此类消息的客户端将处于损坏状态.

The reason that servers typically don't send an "I'm shutting down" message is because many times the server goes down uncontrollably (power outage, operating system crash, fire, short circuit, etc) This means that an protocol which requires such a message will leave the clients in a corrupt state if the server goes down in an uncontrolled manner.

因此，失去连接实际上是对服务器的请求失败的功能.在下一次尝试执行某项操作之前，客户端通常仍将处于运行状态.

So losing a connection is really a function of a failed request to the server. The client will still typically be running until it makes the next attempt to do something.

同样，打开与服务器的连接通常在大多数时间也无济于事.要验证您是否确实与服务器建立了正常的连接，必须向其询问一些数据并得到答复.大多数协议会自动执行此操作以简化逻辑.但是，如果您曾经编写自己的服务，即使您没有从服务器请求数据，即使API指出您的连接"良好，您也可能没有.当您在计算机上成功配置了所有内容后，API可以报告良好的连接".要真正知道它在另一台机器上是否可以100％工作，您需要询问数据(并获取数据).

Likewise, opening a connection to a server often does nothing most of the time too. To validate that you really have a working connection to a server, you must ask it for some data and get a reply. Most protocols do this automatically to simplify the logic; but, if you ever write your own service, if you don't ask for data from the server, even if the API says you have a good "connection", you might not. The API can report back a good "connections" when you have all the stuff configured on your machine successfully. To really know if it works 100% on the other machine, you need to ask for data (and get it).

最后，服务器有时会丢失其客户端，但是由于它们不浪费带宽仅与客户端聊天而不是查看它们是否存在，因此服务器通常会在客户端连接上设置超时".基本上，如果服务器在10分钟内没有收到客户端的声音(或配置的值)，则它将关闭客户端的缓存连接信息(如果客户端返回，则根据需要重新创建连接信息).

Finally servers sometimes lose their clients, but because they don't waste bandwidth chattering with clients just to see if they are there, often the servers will put a "timeout" on the client connection. Basically if the server doesn't hear from the client in 10 minutes (or the configured value) then it closes the cached connection information for the client (recreating the connection information as necessary if the client comes back).

从您的描述中尚不清楚您可能看到的是哪种情况，但是希望此常识可以帮助您理解为什么在关闭连接的一侧后，连接的另一侧可能仍然认为它是开放的一会儿.

From your description it is not clear which of the scenarios you might be seeing, but hopefully this general knowledge will help you understand why after closing one side of a connection, the other side of a connection might still think it is open for a while.

有一些方法可以配置网络连接以更迅速地报告关闭，但除非您愿意为保持活动消息而浪费大量网络带宽并且不希望服务器响应，否则我将避免使用它们尽快.

There are ways to configure the network connection to report closures more immediately, but I would avoid using them, unless you are willing to lose a lot of your network bandwidth to keep-alive messages and don't want your servers to respond as quickly as they could.

这篇关于Elasticsearch未公开客户端. Tomcat关闭后的活动线程.内存使用有何影响?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！