> On Jan. 29, 2013, 1:20 p.m., Kishan Kavala wrote:
> > Wei Zhou,
> > Patch changes the network usage calculation to use current bytes instead of
> > aggregate bytes. Consider the following case:
> > 1. current bytes is updated every 5 minutes
> > 2. usage aggregation is 1440 (daily)
> > 3. usage job runs at 5pm
> >
> > For daily aggregation, records will be generated for 00:00 hrs to 23.59
> > hrs. If I generate 2GB traffic at 6pm on 28th Jan and 3GB at 10am on 29th
> > Jan, as per the fix, 5GB usage will be reported for 28th Jan 00:00 to 23:59
> > hrs when the job runs at 5pm, which is not correct. When aggregate bytes is
> > used for calculation it'll show 2GB usage for 28th Jan correctly.
> >
> > I think the issue is with NetworkStatsUpdateTask in
> > VirtualNetworkApplianceManagerImpl which updates aggregate bytes. There is
> > probably some delay in updating aggregate bytes.
> >
> >
>
> Kishan Kavala wrote:
> You can check op_user_stats_log table to verify if there is any delay in
> updating aggregate stats.
>
> Wei ZHOU wrote:
> Kishan,
>
> yes, you are right. I have not considered that 1440 is a special value
> for statistics, and 60 as well.
> for other value, I still suggest use current bytes instead of aggregate
> bytes.
> This issue is much like a bug of cloudstack. I will continue working on
> this issue.
Kishan,
in com.cloud.network.router.VirtualNetworkApplianceManagerImpl.start(), the
endDate is always less than (=before) System.currentTimeMillis when the range
is 1440 or 60. So NetworkStatsUpdateTask will execute immediately, and every
_usageAggregationRange minutes later. It should be the root cause. The endDate
should be the next execution time.
if (_usageAggregationRange == DAILY_TIME) {
cal.roll(Calendar.DAY_OF_YEAR, false);
cal.set(Calendar.HOUR_OF_DAY, 0);
cal.set(Calendar.MINUTE, 0);
cal.set(Calendar.SECOND, 0);
cal.set(Calendar.MILLISECOND, 0);
cal.roll(Calendar.DAY_OF_YEAR, true);
cal.add(Calendar.MILLISECOND, -1);
endDate = cal.getTime().getTime();
} else if (_usageAggregationRange == HOURLY_TIME) {
cal.roll(Calendar.HOUR_OF_DAY, false);
cal.set(Calendar.MINUTE, 0);
cal.set(Calendar.SECOND, 0);
cal.set(Calendar.MILLISECOND, 0);
cal.roll(Calendar.HOUR_OF_DAY, true);
cal.add(Calendar.MILLISECOND, -1);
endDate = cal.getTime().getTime();
} else {
endDate = cal.getTime().getTime();
}
_networkStatsUpdateExecutor.scheduleAtFixedRate(new
NetworkStatsUpdateTask(), (endDate - System.currentTimeMillis()),
(_usageAggregationRange * 60 * 1000), TimeUnit.MILLISECONDS);
- Wei
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/8971/#review15796
-----------------------------------------------------------
On Jan. 16, 2013, 4:04 p.m., Wei ZHOU wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/8971/
> -----------------------------------------------------------
>
> (Updated Jan. 16, 2013, 4:04 p.m.)
>
>
> Review request for cloudstack, Kishan Kavala and Rohit Yadav.
>
>
> Description
> -------
>
> The usage sever does not handle data in the correct time. For example, it
> regards the data traffic between 9:15-9:30 as the data traffic between
> 9:30-9:45.
> Another example is, it regards the data traffic in the day before yesterday
> as the traffic in yesterday.
>
> Another problem is, when the usage.stats.job.aggregation.range is set to N(
> for example, 15), the usage job handle the data every N+1 minutes( for
> example 16).
>
> This is a patch for this issue (all details are described here:
> https://issues.apache.org/jira/browse/CLOUDSTACK-962)
>
>
> This addresses bug CLOUDSTAC?K-962.
>
>
> Diffs
> -----
>
> server/src/com/cloud/user/dao/UserStatisticsDaoImpl.java fd7795a
> usage/src/com/cloud/usage/UsageManagerImpl.java 53ebb14
>
> Diff: https://reviews.apache.org/r/8971/diff/
>
>
> Testing
> -------
>
> The patch is tested in CloudStack Virtual Router environment (Advanced
> Networking, not Basic Networking).
>
>
> Thanks,
>
> Wei ZHOU
>
>
