I found that some graphs were not correctly calculating the Y min/max so as to permit all items to be viewed. Upon further testing, a reproducible case is caused by the UI not resetting the "graphs_items" table field "type" from 2 to 0.
To reproduce the problem:
1) Pick a host which has something like total disk space and used disk space, where the used is substantially less than the total.
2) Create a graph for the host:
a. Type pie
b. Total space as “Graph sum” <<< This sets up the failure
c. Used space as “Simple”
3) Add (i.e. save).
4) If you query the tables, in graphs_items, the type field is set (as appropriate) to 2. The graph works fine at this point.
5) Now go back in and edit the graph:
a. Change the type to “Normal” first (notice this hides type field)
b. Note that MIN and MAX are set to calculated (no need to change them as it should default)
6) If you query the tables, the type is still set to 2, which ideally would be irrelevant, but (as you see) is not.
7) Display the graph – notice that the Y scale is set based solely on the used space, not the total (the total is likely off the screen entirely).
8) If you use SQL to reset the type from 2 to 0, and redisplay the graph, it scales correctly (at least for me nothing was cached, in theory you might need to stop the server before doing the SQL update, and start after).
This also is inherited with templates, so if you define a graph prototype in this fashion, when the LLD creates the actual graphs, the "2" is propagated to the individual disks and hosts, and continues to cause all (or almost all) of them to function incorrectly.
I would argue there are two separate issues; one is that the type of "2" probably should not even be looked at for line/region graphs, but more to the point when changing the graph type to normal, the graph-sum value should be reset as part of changing the graph type. While either would fix this particular problem, the latter is probably the most conservative fix in case the type=2 is handled differently elsewhere.