monitor FD usage |
||||
Issue descriptionWe have a report that samus 56.0.2924.110 ran out of file descriptors https://feedback.corp.google.com/product/208/neutron?lView=rd&lReport=57830549018 [1354:1569:0413/125419.946641:ERROR:accelerometer_reader.cc(466)] Accelerometer trigger failure: -1: Too many open files [...] [1354:1561:0413/140335.833644:ERROR:socket_posix.cc(82)] CreatePlatformSocket() returned an error, errno=24: Too many open files [...] [1354:1561:0413/154210.879721:ERROR:shared_memory_posix.cc(283)] Creating shared memory in /dev/shm/.com.google.Chrome.14FWNp failed: Too many open files There may be an uptick on M59/M60 during branch point in the 99.9 percentile in Memory.Browser.OpenFDs and Memory.Renderer.OpenFDs. But not fully convincing. Nevertheless we should revisit in a few weeks or with more reports.
,
Jun 16 2017
,
Jun 16 2017
,
Jul 25 2017
Adding some notes here as this seems like the best bug for tracking FD usage going forward. crbug.com/733718 was fixed by raising the file descriptor limit to 8192, so users no longer see browser crashes. This is fine for the short term, but we should understand where the extra file descriptor use came from. I'm not sure how we track this down now-- my only idea is to try a finch experiment where we lower the limit back to 2048 for an experimental group, and have some instrumentation to tell us what's going on.
,
Jun 22 2018
Issue 756411 has been merged into this issue. |
||||
►
Sign in to add a comment |
||||
Comment 1 by manisca...@chromium.org
, Apr 24 2017