GuestNo new alerts

Debug Page

- Updates388
 
Among other things which I'll mention in other topics, I've done a fair bit of work on the Control Panel Debug Page to reflect more parts of Gosora's state and to make the UI less of a mess.





Some of these names may be hard to follow (I'm trying to build friendlier versions of these memory statistics in the memory analytics panes, more work on those to come later!), but they largely reflect names of fields provided by Go's runtime.

Sys is the total amount of memory reserved for the process by the OS.

HeapSys is the total amount of memory reserved for the process' heap. This is where a lot of the long-term shared data lives, this is simplified however as it does more than merely that.

HeapAlloc is the total amount of memory actually being used by the heap. Go will usually hold more memory than it actually needs in reserve, as requesting memory from the OS takes a certain amount of time.

HeapIdle is the portion of the heap which is used, so I guess HeapSys - HeapAlloc.

HeapObjects is the total number of objects allocated on the heap. These may range from tiny one byte things to 1kb monsters.

GCSys is the amount of memory reserved for the garbage collector to do it's work.

There are a bunch of other things too, however a lot of them are internal to Go's runtime and more intended for Go Developers.

Topic / User / Reply Caches show how much room Gosora is currently using in the little data caches. It also shows the maximum capacity of how high they can go, which is usually the value you set in config.json

The bit with the topic list is whether the topic list is asleep. It will usually rebuild itself once every second to keep itself current, however if no replies or topics have been created for a long time (five seconds), then it'll go to asleep until something happens. This is done to save resources.

CPUs refers to the number of available logical cores and doesn't necessarily mean physical CPUs.

Goroutines are light-weight threads of sorts. These are scheduled on real bulkier OS threads by Go's runtime and one can be switched out for another at any moment.
If a request hits a blocking function like say one that pulls data from the database, then another will be switched in to do a bit of work for another user while the first waits for the data to get back.
 


I've added a disk and database section to the Debug Page, so you can see how much space you're wast- using on the drive and how many items there are in some of the important tables like topics, replies, profile replies, activity stream, etc.