4 ms·

I think they're actually talking about blowing out the dentry cache, but sure IO contention is anoyher shared resource in containers. Depending on what you're

by RijilV 9y ago

I think they're actually talking about blowing out the dentry cache, but sure IO contention is anoyher shared resource in containers. Depending on what you're doing you might run into issues in various networking limits (somaxconns comes to mind, as does what's left of the route cache), blowing out the page cache, or something eating up your memory bandwidth (maybe via some unlucky NUMA). All for containers but they don't solve the hard problems folks often ascribe to them, really just shows in most cases you don't need to solve the hard problems. Most of the time what containers are buying you is an easy deployment method that leverages some nice features in the OS to make believe you're on separate machines.

bogomipz 9y ago
>"Depending on what you're doing you might run into issues in various networking limits (somaxconns comes to mind, as does what's left of the route cache)" I'm curious what issue(s) you might be referring to here with the route cache? Could you elaborate?
- RijilV 9y ago
  Sure - The route cache was largely removed in (IIRC) 3.8, but there's still entries that get stored[0]. There's a limit to how many entries Linux will store, and like any LRU-esk data structure rapidly cycling entries through it isn't going to do anything wonderful for your performance, never mind if you actually expected to use any of the cached data for a business performance 'feature'. 25g NIC is an awful lot of 60byte packets. I'm not saying this is going to be a common concern, just that like any other shared kernel resource cgroups and namespaces aren't going to help. 0: https://www.systutorials.com/docs/linux/man/8-ip-tcp_metrics/ https://www.systutorials.com/docs/linux/man/8-ip-tcp_metrics...
  - bogomipz 9y ago
    Sure, that makes sense and thank you for the link. I was curious about your comment: >"25g NIC is an awful lot of 60byte packets." Where are you getting that 60 number from? A minimum IPv4 header is 20 bytes and a minimum TCP header is 20 bytes. Also how would a tiny TCP packet relate to the route cache? Tiny TCP packet are certainly a problem with PPS that a NIC is capable I understand that. Cheers.

by RijilV 9y ago

bogomipz 9y ago

>"Depending on what you're doing you might run into issues in various networking limits (somaxconns comes to mind, as does what's left of the route cache)" I'm curious what issue(s) you might be referring to here with the route cache? Could you elaborate?

RijilV 9y ago
Sure - The route cache was largely removed in (IIRC) 3.8, but there's still entries that get stored[0]. There's a limit to how many entries Linux will store, and like any LRU-esk data structure rapidly cycling entries through it isn't going to do anything wonderful for your performance, never mind if you actually expected to use any of the cached data for a business performance 'feature'. 25g NIC is an awful lot of 60byte packets. I'm not saying this is going to be a common concern, just that like any other shared kernel resource cgroups and namespaces aren't going to help. 0: https://www.systutorials.com/docs/linux/man/8-ip-tcp_metrics/ https://www.systutorials.com/docs/linux/man/8-ip-tcp_metrics...
- bogomipz 9y ago
  Sure, that makes sense and thank you for the link. I was curious about your comment: >"25g NIC is an awful lot of 60byte packets." Where are you getting that 60 number from? A minimum IPv4 header is 20 bytes and a minimum TCP header is 20 bytes. Also how would a tiny TCP packet relate to the route cache? Tiny TCP packet are certainly a problem with PPS that a NIC is capable I understand that. Cheers.