hlo في الثلاثاء، 14 يونيو 2022 في تمام الساعة 4:41:21 ص UTC+3، كتب ho...@google.com رسالة نصها:
> Which gRPC library are you using? And which language? C++, Java, Python, > etc > On Monday, June 6, 2022 at 11:42:26 AM UTC-7 amandee...@gmail.com wrote: > >> So, we identified that it might be because of >> CodedInputStream::ReadStringFallback in protocol buffers. >> We do not reserve the buffer upfront and use string's append repeatedly >> for some reason. This leads to a string capacity of 8MB for a 4MB string. >> >> Any pointers would be helpful. >> On Thursday, May 26, 2022 at 2:52:14 PM UTC-4 amandee...@gmail.com wrote: >> >>> We have a mechanism to limit the memory used by a process. To make sure >>> that there are no violators, we rely on maxrss of the process. We check >>> maxrss every few mins to see if we had seen a spike in memory which was >>> beyond the permitted value. >>> >>> We have a grpc server and what we are seeing is that for a request with >>> 4MB of payload, the maxrss of the process is becoming slightly greater than >>> 8MB. This limits our effective memory utilization to just half in most of >>> the scenario without violating the memory limit. My guess it that this is >>> because grpc is not zero copy. Is there a way to make grpc zero copy? If >>> not, is there a way to limit the spike in memory when multiple requests >>> come in? >>> >> -- You received this message because you are subscribed to the Google Groups "grpc.io" group. To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/fc245b3e-6cd0-4cf0-afe3-fb01dfb2a3abn%40googlegroups.com.
