Skip to content
  • Marc Alff's avatar
    5a5ce5ec
    Bug#15927744 - DEFAULT P_S CONFIGURATION WASTES CPU ON A BUSY SERVER · 5a5ce5ec
    Marc Alff authored
    Prior to this fix, performance schema configuration variables that
    can be automatically sized by the server were given incorrect values
    in some cases.
    
    Performance overhead can increase significantly
    with some pathological cases created by incorrect sizing,
    causing this bug to have a real impact.
    
    For example, for 50,000 tables in the table open cache,
    the performance schema estimated that a value of 20,000 table handles
    was adequate. This is wrong, a proper value should be 100,000 in this case.
    
    The problem is that the heuristic used values that got altered by 
    a 'sanitizing' step, supposed to prevent bad usages.
    
    The fix is to simply remove this sanitizing step, because:
    - it does not resolve any problem by itself, only creates more,
    - it introduces hard coded values which are not based on real deployments in
      production
    
    With this fix, heuristics computed by the performance schema for automated 
    sizing are expected to be more adequate, for high end configurations.
    5a5ce5ec
    Bug#15927744 - DEFAULT P_S CONFIGURATION WASTES CPU ON A BUSY SERVER
    Marc Alff authored
    Prior to this fix, performance schema configuration variables that
    can be automatically sized by the server were given incorrect values
    in some cases.
    
    Performance overhead can increase significantly
    with some pathological cases created by incorrect sizing,
    causing this bug to have a real impact.
    
    For example, for 50,000 tables in the table open cache,
    the performance schema estimated that a value of 20,000 table handles
    was adequate. This is wrong, a proper value should be 100,000 in this case.
    
    The problem is that the heuristic used values that got altered by 
    a 'sanitizing' step, supposed to prevent bad usages.
    
    The fix is to simply remove this sanitizing step, because:
    - it does not resolve any problem by itself, only creates more,
    - it introduces hard coded values which are not based on real deployments in
      production
    
    With this fix, heuristics computed by the performance schema for automated 
    sizing are expected to be more adequate, for high end configurations.
Loading